Philips PARREC conversion scaling error for scans with multiple cardiac phases

[ZieroNLD]

Dear dcm2niix team,

Was trying to convert Philips PARREC conversion for a scan that uses multi cardiac phases
however I noticed that the scaling for the cardiac phases, other than the first cardiac phase, is different
This is the case for both versions v1.0.20200427 and v1.0.20200331, but an older version does work! (v1.0.20190902 )
Would be great to resolve this

My best,
Jeroen

Note this is mulitphase ASL that uses the cardiac phase loop to acquire data in a Look Locker fashion

Here it fails:

dcm2niix -z y -b y -f %p_%s test
Chris Rorden's dcm2niiX version v1.0.20200427 (JP2:OpenJPEG) GCC8.3.0 (64-bit Linux)
Found 1 DICOM file(s)
Warning: dcm2niix PAR is not actively supported (hint: use dicm2nii)
Warning: Reported TR=583.737ms, measured TR=12013ms (prospect. motion corr.?)
Warning: Distance between slices reported by slice gap+thick does not match estimate from slice positions (issue 273).
Done reading PAR header version 4.2, with 3840 slices
Warning: Multiple Echo (1) or Cardiac (5). Carefully inspect output
no Varies
1.26422 0 0.011024
Philips Scaling Values RS:RI:SS = 1.26422:0:0.011024 (see PMC3998685)
Convert 1 DICOM as test/WIPSOURCE-ASLmPhase5_5_t1516 (80x80x16x48)
Compress: "/usr/bin/pigz" -b 960 -n -f -6 "test/WIPSOURCE-ASLmPhase5_5_t1516.nii"
no Varies
1.26422 0 0
Convert 1 DICOM as test/WIPSOURCE-ASLmPhase5_5_t2087 (80x80x16x48)
Compress: "/usr/bin/pigz" -b 960 -n -f -6 "test/WIPSOURCE-ASLmPhase5_5_t2087.nii"
no Varies
1.26422 0 0
Convert 1 DICOM as test/WIPSOURCE-ASLmPhase5_5_t2658 (80x80x16x48)
Compress: "/usr/bin/pigz" -b 960 -n -f -6 "test/WIPSOURCE-ASLmPhase5_5_t2658.nii"
no Varies
1.26422 0 0
Convert 1 DICOM as test/WIPSOURCE-ASLmPhase5_5_t3229 (80x80x16x48)
Compress: "/usr/bin/pigz" -b 960 -n -f -6 "test/WIPSOURCE-ASLmPhase5_5_t3229.nii"
no Varies
1.26422 0 0
Convert 1 DICOM as test/WIPSOURCE-ASLmPhase5_5_t3800 (80x80x16x48)
Compress: "/usr/bin/pigz" -b 960 -n -f -6 "test/WIPSOURCE-ASLmPhase5_5_t3800.nii"

Here it works correctly

dcm2niix20190902 -z y -b y -f %p_%s test
Chris Rorden's dcm2niiX version v1.0.20190902 (JP2:OpenJPEG) (JP-LS:CharLS) GCC5.5.0 (64-bit Linux)
Found 1 DICOM file(s)
Warning: dcm2niix PAR is not actively supported (hint: use dicm2nii)
Warning: Reported TR=583.737ms, measured TR=12013ms (prospect. motion corr.?)
Warning: Distance between slices reported by slice gap+thick does not match estimate from slice positions (issue 273).
Done reading PAR header version 4.2, with 3840 slices
Warning: Multiple Echo (1) or Cardiac (5). Carefully inspect output
Philips Scaling Values RS:RI:SS = 1.26422:0:0.011024 (see PMC3998685)
Convert 1 DICOM as test/WIPSOURCE-ASLmPhase5_5_t1516a (80x80x16x48)
Compress: "/usr/bin/pigz" -b 960 -n -f -6 "test/WIPSOURCE-ASLmPhase5_5_t1516a.nii"
Philips Scaling Values RS:RI:SS = 1.26422:0:0.011024 (see PMC3998685)
Convert 1 DICOM as test/WIPSOURCE-ASLmPhase5_5_t2087a (80x80x16x48)
Compress: "/usr/bin/pigz" -b 960 -n -f -6 "test/WIPSOURCE-ASLmPhase5_5_t2087a.nii"
Philips Scaling Values RS:RI:SS = 1.26422:0:0.011024 (see PMC3998685)
Convert 1 DICOM as test/WIPSOURCE-ASLmPhase5_5_t2658a (80x80x16x48)
Compress: "/usr/bin/pigz" -b 960 -n -f -6 "test/WIPSOURCE-ASLmPhase5_5_t2658a.nii"
Philips Scaling Values RS:RI:SS = 1.26422:0:0.011024 (see PMC3998685)
Convert 1 DICOM as test/WIPSOURCE-ASLmPhase5_5_t3229a (80x80x16x48)
Compress: "/usr/bin/pigz" -b 960 -n -f -6 "test/WIPSOURCE-ASLmPhase5_5_t3229a.nii"
Philips Scaling Values RS:RI:SS = 1.26422:0:0.011024 (see PMC3998685)
Convert 1 DICOM as test/WIPSOURCE-ASLmPhase5_5_t3800a (80x80x16x48)
Compress: "/usr/bin/pigz" -b 960 -n -f -6 "test/WIPSOURCE-ASLmPhase5_5_t3800a.nii"

[neurolabusc]

Jeroen-

1. For complex sequences like mulitphase ASL, I would heed the words of Matthew Clemence (a Philips Senior Clinical Scientist): the PAR-REC format was built for simpler times. I would strongly suggest exporting these sequences as enhanced DICOM.
2. As the output you provide notes: dcm2niix PAR is not actively supported (hint: use dicm2nii).

The PAR/REC format is a proprietary Philips format, and they developed it in ways I had not envisioned when I wrote my code (e.g. slices saved as they come off the reconstructor rather than as acquired). In addition, there are some documented errors introduced by some Philips tools that require odd kludges. The result is that the dcm2niix code is not well suited for the images seen in the wild, and difficult to maintain.

If you really want to proceed, you have two options:

1. Make a fork of dcm2niix, adapt it to deal with your images and submit a pull request to share your solution with the community. I would be happy to make you maintainer for the PAR/REC support of dcm2niix (please).
2. Send a sample dataset that exhibits the issue via DropBox/GoogleDrive/etc with a link to my email address (shown in my avatar). I can not promise this will be a high priority to me. I enjoy supporting this format like most people enjoy going to the dentist.

[ZieroNLD]

Dear neurolabusc,
Thank you for the swift reply, we will use the workaround for now (ie the older dcm2niix version), and will proceed to export the multiphase ASL using enhanced DICOM.

Best Jeroen

[ZieroNLD]

as for the multiband BOLD, unfortunately, the enhanced DICOM export on Philips scanner does not work well when having too many total slices (number of volumes * slices per volume), which is especially problematic with multiband BOLD data as the TR is rather short and total scan duration is long (10-15min). For these large datasets the system will fall back to classic DICOM, resulting in lots and lost of separate files for the MB-BOLD. This is an issue I'd have to address with Philips o improve the enhanced DICOM export for large datasets.

weird though that it did work before with dcm2niix

[neurolabusc]

This is a proprietary format, and from a developers perspective Philips has been modifying the format (though it might be internally consistent from their perspective). dcm2niix had to be modified to handle some of these changes. Clearly, there was an unintended consequence for your data. I would be wary of using the older version, as the changes made to the newer versions were intentional to cope with changes in how Philips stores data in this format. Therefore, while the old software may work in this specific instance, it will certainly fail with some images.

You may want to look at the commit and issue history to see when this change was introduced.

[neurolabusc]

This should be fixed. The latest commit can convert PAR/REC slices with up to 64000 slices, if this is exceeded it will ask you to recompile after increasing kMaxSlice2D in nii_dicom.h. Information is now stored on the heap instead of the stack, so the only consequence of increasing this value will be that dcm2niix will use a bit more RAM. In the future, this can be extended to dynamically increase, similar to what we do with 2D slices.