Hello Everyone,

I am trying to convert my dicom files using dcm2niix version v1.0.20170429 and unfortunately I keep getting flipped data in voxel space. Flip happens for both pre-clinical and clinical data, invariant of the scanner (tried for both Bruker 70/30 USR and Siemens Triotim respectively). The command that I've been running is as follows:

./dcm2niix -s y -p n -o 'output/dir' 'path/to/dicom/file'

The flip seems to happen along the same axis for both clinical and pre-clinical data's voxel space. I've verified such flip on nibabel. Has anyone encountered this problem before? Any help would be greatly appreciated.

Thank you in advance.

Regards,
Anderson Napolitano

What tool are you using to view your data - is it possible that your image viewer is not aware of the spatial transformation matrices stored in the NIfTI header? I would suggest you use a tool like MRIcroGL or SPM to view your data (as these leverage the NIfTI header). One thought is that these are 3D images, which dcm2niix is losslessly rotating to the nearest orthogonal rotation to match an identity matrix. When the software does reorient the images in this manner, it updates the spatial transformation information stored in the header.

I am not familiar with nibabel, but I think it is aware of the coordinate systm, but initially shows you the raw data without applying the transform
http://nipy.org/nibabel/coordinate_syste...

Hi Dr. Rorden,

I am using a commercial software called 'Vivoquant' to view the data. I, however, tried your data on both SPM and MRIcroGL and for both instances, the images still appears to be flipped. I've attached a screen capture of the images viewed through MRIcroGL.

Regarding your concerns about the images being 3D, I've tested dcm2niix binary on both 3D (pre-clinical) and 2D (clinical) images and for both attempts, I get a flipped image on the same axis. 

As for the rotations, I will have to read more into the source of your code to see what actually is happening in the internals. Do you recommend a particular excerpt in the source?

I will be investigating the affine mapping from voxel space to subject-scanner reference space soon to see if the affines are accurate to the voxel space flip.

Anyways, thank you so much for replying. I really appreciate the help.

Regards,
Anderson

Hi Dr. Rorden,

Sorry for responding again without waiting for your response but I would just like to know your opinion about what I have found earlier regarding the conversion.

I imported both the original data and the dcm2niix-converted data through nibabel to verify that the voxel space is indeed flipped. It is flipped. From there, I've checked both of their affine matrices and both seems to be different, so I though maybe I can check to see if such flip is reflected on their respective affines.

The affines for the original image and the converted image is:

A_orig = [[ 0.29249999, 0. , 0. , -37.29374695],
[ 0. , 0.29249999, 0. , -37.29374695],
[ 0. , 0. , -0.29249999, 1.60874999],
[ 0. , 0. , 0. , 1. ]]

Orientation_orig = (R,A,I)

A_conv = [[ -0.078125 , 0. , -0. , 9.06762981],
[ -0. , 0.0859375 , -0. , -14.87300301],
[ 0. , 0. , 1.15999997, -9.28507042],
[ 0. , 0. , 0. , 1. ]]

Orientation_conv = (L,A,S)

respectively. The image that I'm working with (256,256,12) is flipped by the z-axis (if the matrix is viewed with 256 * 256 slice facing the observer) after conversion. Hence, voxel (0,0,0) translates to (0,255,0) after conversion in the voxel space.

One would expect that by mapping both voxel coordinates to the subject-reference space (taking note of their respective affines and orientations) that we will get the same subject-reference space locations.

Multiplying (0,0,0,1) to A_orig gives: [-37.29374695, -37.29374695, 1.60874999, 1. ]

and 

Multiplying (0,255,0,1) to A_conv gives: [ 9.06762981, 7.04105949, -9.28507042, 1. ]

If we take their respective orientations into account, voxel (0,0,0) is 37.3 to the left of the subject-scanner reference space origin and voxel (0,255,0) is only 9.06 mm to the left of the subject-scanner reference space origin.

These does not agree which means that the converted image's affine does not reflect such flip.

Are you seeing anything wrong with my computation?

Thanks you so much,
Anderson

Anderson-

Just remember that DICOM and NIFTI use a different coordinate systems
   https://www.slicer.org/wiki/Coordinate_systems
I am not familiar with NiBabel, but I suspect this explains the difference.

To convince yourself of this, look at a scan in a nice DICOM aware tool (like Osirix) and then the dcm2niix converted DICOM with SPM. You should see that the spatial position is preserved, it is simply transformed to a different coordinate system. We do this with the NIfTI SForm and QForm so that the raw data is losslessly copied unchanged. By the way, I usually like to place a vitamin E capsule on the left temple as a fiducial marker. It shows up nicely on the high resolution T1 scan (where segmentation has no difficulty segmenting it), but is invisible on the DTI/fMRI sequences so it has not impact on motion correction.

Hi Dr. Rorden,

Thank you so much. Such orientation difference really does explain the difference in affine matrices. I derived my dicom image's affine based-off the following dicom attributes:

(0010,2210) Anatomical Orientation
(7FE0,0010) Pixel Data
(0028,0030) Pixel Spacing
(0020,0032) Image Position Patient
(0020,0032) Image Orientation Patient 

and I was able to derive my dcm2niix-converted image's affine matrix from a permutation matrix multiplied to the affine. 

Bottom line is your software, dcm2niix, is flawless and I just did not pay enough attention to details.

Thank you so much Dr. Rorden. I really appreciate your help.

Regards,
Anderson

Hello,

I am having some issues using dcm2niix to convert my DICOMs to NIFTI files that make me question the handling of orientation information within the file. My viewing tool for both file formats has been Mango. When I view the original DICOM, everything appears to be oriented correctly. Upon conversion, the image is flipped. This is problematic because my flipped image is registered to a template that is correctly oriented, resulting in a flipped and failed registration. However, when I use Mango to save my DICOM as a NIFTI file, the orientation and subsequent registration proceed correctly.

I have a large number of images I would like to process, so dcm2niix is an attractive tool for automatic conversion rather than launching Mango to save images one at a time. Is there any other information I could provide that would help diagnose the issue?

Thank you!

Lindsay

I am not a regular Mango user, but given the thousands of datasets that have been processed with dcm2niix I would be very surprised if it is making errors with spatial transforms. The explanation for this difference for many tools such as Slicer is that DICOM and NIfTI report the polarity of the X dimension oppositely: for DICOM X increases as you move left and with NIfTI it increases as you move right
https://www.nitrc.org/plugins/mwiki/inde...
You can easily check this by opening up your DICOM data with a dedicated DICOM viewer like Osirix: find a feature that appears on the left side of the participant. Next, load the NIfTI image with a tool that reads the NIfTI spatial transforms like MRIcroGL. Make sure to check whether the tool views in neurological or radiological convention (with MRIcroGL, you can use the Display/Radiological menu item to choose between these) - https://www.nitrc.org/plugins/mwiki/index.php/mricrogl:MainPage#Neurological_versus_radiological_convention

The feature on the patients left should remain on the patients left. If this is not the case, please file a bug report on the dcm2niix github web page. If things work out, you may want to check the Mango documentation and ask them to explicitly state how coordinates are shown from these different sources.

Lindsay-
 Thanks for the examples. These DICOM files provide no spatial coordinates, so all DICOM to NIfTI converters fail in different ways. I have provided a kludge in the latest release of dcm2niix that seems to match the vendor's software
 https://github.com/rordenlab/dcm2niix/releases
The vendor seems responsive to fixing this.