[imaging_browser] Modify content of table displaying image headers information

[cmadjar]

Brief summary of changes

This PR modifies the information displayed in the headers table. Modifications include:

• addition of Image Type, Phase Encoding Direction, Echo Number and Inversion Time parameters to the table
• addition of Processing Pipeline and Processing Date in the list of displayed header if those contain values
• removal of pipeline and algorithm headers since they have been removed from the DB a few years ago and therefore will always be empty
• display DTIPrep specific headers only for images that has ProcessingPipeline set to 'DTIPrepPipeline'
• if Number of Volumes is 0, do not display any value instead of showing 0.00 volumes
• for Number of Volumes that are not set to 0, display the number of volumes as integer instead of floats (example: 200 volumes instead of 200.00 volumes)

Testing instructions

1. Check out this branch, run make dev and look at the header table.
2. Volumes should be displayed only for fMRI or DWI data that have multiple volumes and should be displayed as integer instead of floats
3. Ensure that the new header information are showing when the scan have parameters for those headers
4. Ensure that the default DTIPrep headers are not showing for images that are not produced by DTIPrepPipeline

Link(s) to related issue(s)

• Resolves https://github.com/aces/HBCD/issues/229

[driusan]

Is there a reason this needs to go to 24.1 instead of main? We should be prioritizing releasing 24.1 at this point..

[cmadjar]

@driusan this is to avoid any overrides in HBCD. Also, the PR fixes a lot of different bugs in the table displaying the headers...

[nicolasbrossard]

@cmadjar I might be having an issue with the processing date but wanted to confirm with you. I added a dummy record in parameter_file for one of the files on raisin bread and set the value to 20140206 (that's how the processing dates are stored in IBIS). When I looked at the headers, the pipeline processing date displayed was 1391706000 (most likely the Unix timestamp representation of that date). Bug?

[cmadjar]

@nicolasbrossard weird. It was getting the date via the _getDate function of viewsession.class.inc which converts dates to timestamps for some reason. Not sure about the utility of that function... Anyway, I corrected the processing date so that it displays what is present in the parameter_file table.

I also resolved the conflict with the CHANGELOG.

[nicolasbrossard]

@cmadjar Works fine now. Approving.