Philips PARREC conversion for long multiband BOLD crashes

[ZieroNLD]

Dear dcm2niix team,

Was trying to convert Philips PARREC conversion for long multiband BOLD fMRI series (15min)
unfortunately dcm2niix crashes with the following error message
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

FAILS to CONVERT

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: PAR/REC intensity scaling varies between slices (please validate output).
Warning: Expected 1033193494 slices, but found 51 (1..51). test/SUBJNAME^M.B^^^_BOLD_MB_ACZ_15min_7_1.PAR
Warning: Reported TR=0.0728914ms, measured TR=1050ms (prospect. motion corr.?)
Warning: PAR file volumes not saved in ascending temporal order (please check re-ordering)
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 43350 slices
Error: Unable to convert DTI [increase kMaxDTI4D] found 1033193494 directions
*** stack smashing detected ***: terminated
Aborted

THIS WORKS

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: PAR file volumes not saved in ascending temporal order (please check re-ordering)
Done reading PAR header version 4.2, with 43350 slices
Philips Scaling Values RS:RI:SS = 0.82247:0:0.0728914 (see PMC3998685)
Convert 1 DICOM as test/BOLDMBACZ15min_7 (96x96x51x850)
Compress: "/usr/bin/pigz" -b 960 -n -f -6 "test/BOLDMBACZ15min_7.nii"
Conversion required 14.560835 seconds (7.389468 for core code).

[neurolabusc]

See my comments for issue 461

[neurolabusc]

If you edit nit_dicom.h and change the line

static const int kMaxDTI4D = 18000; 

to read

static const int kMaxDTI4D = 65000; 

and recompile, does it work with your dataset?

At the moment, this structure is created on the stack, and setting a large value may cause issues for some compilers on the Windows operating system. Large values are really only used for the new PAR/REC unscrambling. If this resolves your issue, this could be created dynamically on the heap instead. When dcm2niix was designed, DICOMs were 2D images. The modern era of enhanced DICOM and multi-band do require making some of these dynamic arrays.

[ZieroNLD]

Dear Chris, Thanks for the advice, I tried it but to no alas unfortunately; tried lower values than 65000 as well; 19000, 24000, 48000 for the kMaxDTI4D but these also gives me a segmentation fault: Chris Rorden's dcm2niiX version v1.0.20201102 GCC8.3.0 x86-64 (64-bit Linux) Found 2 DICOM file(s) Warning: dcm2niix PAR is not actively supported (hint: use dicm2nii) Done reading PAR header version 4.2, with 180 slices Warning: Overwriting existing file with the name BOLD_PARREC/WIPsT13DTFE_12 Philips Scaling Values RS:RI:SS = 2.98852:0:0.00653545 (see PMC3998685) Convert 1 DICOM as BOLD_PARREC/WIPsT13DTFE_12 (240x240x180x1) Compress: "/usr/bin/pigz" -b 960 -n -f -6 "BOLD_PARREC/WIPsT13DTFE_12.nii" Warning: dcm2niix PAR is not actively supported (hint: use dicm2nii) Warning: PAR/REC intensity scaling varies between slices (please validate output). Warning: Expected 1032054294 slices, but found 51 (1..51). BOLD_PARREC/FRITZ-ASADI^M._WIP_BOLD_MB_ACZ_15min_9_1.PAR Warning: Reported TR=0.0644037ms, measured TR=1050ms (prospect. motion corr.?) Warning: PAR file volumes not saved in ascending temporal order (please check re-ordering) 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 43350 slices Error: Unable to convert DTI [increase kMaxDTI4D] found 1032054294 directions Segmentation fault In addition, I tried to increase the kMaxslice2D, from 64000 to 96000 and 128000, but doesn’t work either. As a sanity check I tested my compiled dcm2niis on an anatomy MRI dataset (T1w3D MPRAGE) and this does convert nicely. Note, our MB BOLD dataset we use In the clinic has 51 slices and 850 volumes, i.e. in total 43350 slices. If it helps I could send you such a dataset? For the multiphase ASL we will go to enhanced DICOM as you suggested, only need a solution for the MB BOLD. The Philips system can convert to NIFT already on the scanner, but then unfortunately we don’t have the .json meta file… Best regards, Jeroen S

…

On Thu, Dec 10, 2020 at 7:07 PM Chris Rorden ***@***.***> wrote: If you edit nit_dicom.h and change the line static const int kMaxDTI4D = 18000; to read static const int kMaxDTI4D = 65000; and recompile, does it work with your dataset? At the moment, this structure is created on the stack, and setting a large value may cause issues for some compilers on the Windows operating system. Large values are really only used for the new PAR/REC unscrambling. If this resolves your issue, this could be created dynamically on the heap instead. When dcm2niix was designed, DICOMs were 2D images. The modern era of enhanced DICOM and multi-band do require making some of these dynamic arrays. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#460 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APW6L3RMJILCYMJ7CSI54QLSUEE6HANCNFSM4UUXFDPA> .

[drmclem]

HI

I would have thought that this was the problem

Expected 1033193494 slices, but found 51 (1..51).

That number looks very wrong.

Matthew

[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.

[drmclem]

For info - the maximum (currently) number of slices on Philips for 1 single scan enitiy is 65535.

M