Greetings,

I have been trying to convert the attached DICOMs to NIFTI, all of which belong to the same 3D GRE Siemens sequence. The sequence outputs 2 GRE magnitude images corresponding to 2 different echos and a single phase image which is calculated from the 2 separate phase echos (I believe it is a subtraction of the two which happens at the MRI scanner level). The output is 108 DICOMS (54x2 echos) for the 2 magnitude images (labelled as Sequence 0011) and another 54 DICOMs for the single phase image (labelled as Sequence 0012).

It appears dcm2niix (v1.0.20190902 & v1.0.20201102) recognizes these sequences when pointed to their folder:

Warning: Images sorted by instance number [0020,0013](1..54), but AcquisitionTime [0008,0032] suggests a different order (162112..162111)
Warning: Unable to determine slice direction: please check whether slices are flipped
Convert 108 DICOM as COPY_DTICENTER_FieldMapping/COPY_DTICENTER_FieldMapping_COPY_DTICENTER_Field_Mapping_20210119154708_11_e2 (78x78x54x2)
Convert 54 DICOM as COPY_DTICENTER_FieldMapping/COPY_DTICENTER_FieldMapping_COPY_DTICENTER_Field_Mapping_20210119154708_12_e2_ph (78x78x54x1)

However, the converted magnitude image (4D NIFTI with 2 echos) only has 2 voxels per volume and they look like a 2x2 matrix of differently colored rectangles. The Phase image looks correct. This only happens if the -m 1 option is provided (merge 2D slices from same series). with -m 2 or removing the -m option results in two separate magnitude image NIFTI files that look correct.

This problem does not occur with an old version of dcm2nii (2MAY2016 64bit)

Any thoughts?

Thank you,

Valentinos

This is a known limitation of Siemens Fieldmaps. The instance number is repeated for each echo, so for your 27-slice volume you have the instance numbers 1..27 each repeated twice rather than 1..54. This is technically legal, as the DICOM standard does not require that instance numbers are unique. However, most tools assume these are unique.However, in my experience this is a major reason for dataloss, as many archiving tools overwrite some conflicting files (e.g. resulting in 27 DICOM slices that are a mixture of the two echos). In general, I would keep the default merge option ("-m 2"). The other values should only be used to resolve mis-behaved DICOMs. In this instance "-m 2" does what it says on the tin, forcing "merge 2D slices from same series regardless of echo, exposure, etc". The unintended consequence is clear. For details see here. I would urge you to join me in lobbying your Siemens Research Collaboration Manager to have this resolved in a future software release.

Thank you for the quick response.