Dear Chris,

I am trying to convert an old set of Philips dwi data in DICOM format to nii. The data consists of one file per slice and after conversion, the slices are obviously mixed up between frames (one or two b0 slices appear in each frame). The spatial slice order is retained though, i.e. the images look like brains.
I remember having problems with this dataset a few years ago and worked around it with an old version of dcm2nii by sorting slices into subfolders based on DiffusionGradientOrientation but this no longer works and the old nii files are lost.

I have more recent data using the same sequence which converts fine so I guess some crucial field is missing. However, the information to sort slices properly should still be there?

I attach the dicom header in json format from a slice of the working and nonworking dataset, respectively, in case it helps.

Best regards,

Jonas

The JSON-ified DICOM headers are not very insightful. You may find that using dcmdump or gdcmdump (e.g. "dcmdump img.dcm > img.txt") is more meaningful, as it will reveal if your tags were mangled by a PACS system like AGFA or dicom4che. 


If the latest stable version fails,  latest commit on the development branch resolve your issue? You can build this using the recipe below:

If you use Windows: you can get a pre-compiled version of the development branch from AppVeyor (https://ci.appveyor.com/project/neurolab...) (click on the Artifacts button).

If you use UNIX, you can build your own copy of the development branch:

'''
git clone --branch development https://github.com/rordenlab/dcm2niix.gi...
cd dcm2niix/console
g++ -I. main_console.cpp nii_foreign.cpp nii_dicom.cpp jpg_0XC3.cpp ujpeg.cpp nifti1_io_core.cpp nii_ortho.cpp nii_dicom_batch.cpp -o dcm2niix -DmyDisableOpenJPEG
./dcm2niix ....
'''

If this does not resolve your issue, you can generate a Github issue report
  https://github.com/rordenlab/dcm2niix

Thank you for a quick reply!

The latest development build has the same issue. It's obvious from running dcmdump that a lot of dicom fields are missing.

I do remember now that I previously converted one volume at a time after sorting by diffusion gradient direction and then combined them. I am not sure that this is even a valid approach, but it solved the mixup of slices. Maybe using diffusion gradient direction as a fallback option in dcm2niix could be a solution?

I can file a report if you think this is a valid issue.

Best,
Jonas

You need to be aware that Philips scanners can emit images in the order that they come out of the parallel reconstructor pipeline, which is often different from the temporal order that the images were acquired. For this reason, dcm2niix really needs the full meta data to recombine slices correctly. While your method by attempting to reorder based on diffusion direction may work in your situation, it might not work as expected if a gradient direction is repeated across separate volumes. I would also worry what other meta data is missing. For all these reasons, I would be concerned about using dcm2niix for your dataset. 

If I were you, I would consider making a custom version of dicm2nii (Matlab) or dicom2nifti (Python)
  https://github.com/xiangruili/dicm2nii
  https://github.com/icometrix/dicom2nifti
Using a scripting language based converter will be much easier for customizing to handle your mangled data.

Ok, I see the problem.

I was able to modify dicm2nii to work with my data. Basically, it seems to rely on InstanceNumber for correct ordering, but slices from the first 2-3 frames have overlapping instance numbers and are intermingled with the other slices. So once again relying on diffusion directions worked here.

Hoever, the actual voxel values are very different to the non-mangled dataset, being integer values. Looks like UINT8, actually (max value 239). I guess this is due to the RescaleSlope being set to 1? Does this matter at all or is it just a global scaling of intensities?

Again, thanks a lot for your help!

Can you share the DICOM images directly with me (email a link to the DropBox/GoogleDrive file to my email)? Data saved as UINT8 would seem to have very little dynamic range. The text files you provided suggest that BitsStored is 12, so one would expect values in the range 0..4095, typically with the b=0 volume using most of this dynamic range, with b-weighted scans having less signal.

I'll need to revise that a bit. The maximum value is actually 1008. I got 239 from just looking at the max intensity setting in MRicroGL (still most values would fit in 8 bit...).

I will share a folder with you via mail!

Originally posted by Chris Rorden:
Note that Philips does not allow repeating (|b|, direction) in the same scan, so if the sort by direction also included b value as a key it would probably work.

This feature is usually a minor nuisance; to get repeated b ~ 0 volumes on Philips I start with 1 b=0, and then intersperse a few b = 2 s/mm^2 volumes with different directions throughout the scan.

Rob