Direction/Orientation matrix DICOM vs Nifti

Hi everyone,

I’m re-posting a question that I recently asked in the SimpleITK Discourse ( It may seem a bit redundant, but I would like to have your thoughts considering that conversion DICOM to Nifti is the initial step in the creation of a BIDS structure.

In short, using ITK based tools (elastix, ANTS, SimpleITK, MeVisLab, and maybe more), I notice that the Direction Matrix I read from DICOMs is different compared to the one is set in Niftis for the same image. This affects some algorithms working in world coordinates, particularly registration operations.

Have any of you perceived these inconsistencies with the Niftis ? There is a good amount of info on the q_form and s_form of the orientation matrix in Niftis, but I have not seen any formal consistency checks between the original DICOMs and generated Niftis. Are you aware of anything like this?



I’m not sure I understand the questions posed here. From the linked thread, it seems that there is concern over losing the precision when moving from a 64-bit float affine matrix to a 32-bit float affine matrix.

This seems plausible, but are these effects problematic in some way? If you consider your starting point a few nm off from where it is otherwise, then the transformation found by your registration algorithm may also be a few nm different, but I would be surprised if the registration was worse in a measurable way.

I would assume that this is built into the testing framework of the converters, such as dcm2niix.

If what you want is to be able to encode your affine matrices as 64-bit floats, the NIfTI-2 format will do that for you. It doesn’t look like dcm2niix supports NIfTI-2, but you should be able to recover it pretty easily in Python (I haven’t tested this…):

import nibabel as nb
from nibabel.nicom.dicomwrappers import wrapper_from_file
dcm = wrapper_from_file(dcm_fname)
nii = nb.load(nii_fname)
nii2 = nb.Nifti2Image(nii.dataobj, dcm.affine, nii.header), nii2_fname)

There are two issues here. First, the NIfTI uses a different spatial coordinate system than DICOM. Specifically, NIfTI uses Talairach-Tournoux coordinates:
X: Increasing value toward the Right
Y: Increasing value toward the Anterior
Z: Increasing value toward the Superior
In contrast, the DICOM coordinate system is
X: Increasing value toward the Left
Y: Increasing value toward the Posterior
Z: Increasing value toward the Superior
The other thing to remember is the row order. Following NIfTI convention I will refer to the stored order as I,J,K instead of X,Y,Z to avoid confusion with spatial dimensions. The data is stored Columns (I) followed by Rows (J) followed by slices (K). For a NIfTI image
I: first column on LEFT of screen, columns ascending toward RIGHT
J: first row at BOTTOM of screen, subsequent columns ascending toward TOP
with DICOM
I: first column on LEFT of screen, columns ascending toward RIGHT
J: first row at TOP of screen, subsequent columns ascending toward BOTTOM
I like to think of how we draw a 2D Cartesian graph, with a higher position on the graph showing a higher value. In contrast, DICOM is how I write English, with the first row at the top of the screen and subsequent rows descending down the page.

dcm2niix will losslessly convert DICOM to NIfTI. It will preserve spatial information. By default, it will also flip the row order. This flipping means that a viewing tool that ignores the Form/QForm will display a 2D slice in the same way that a DICOM viewer would with respect to the top and bottom of the computer screen. The undocumented argument -y n will disable this row flipping. Since the SForm/QForm are also updated, the resulting images will look identical in a tool that respects the SForm/QForm, but will look flipped in tools that ignore this. To see this, launch MRIcron and choose Preferences. Make sure both the “Reorient images when loading” and “Rotate to nearest orthogonal angle” options are unchecked. This will show the order data is saved to disk.

rcorredorj here are the consistency checks used by dcm2niix. Each commit of code for the dcm2niix code is automatically run through several of these validation datasets to detect regressions. Each validation set includes some DICOMs and their correct conversion to NIfTI. Different validation datasets are used to test different features of the DICOM format (which is very complex and has been interpreted differently by different vendors). DICOM is like the English language and used differently by different groups (e.g. for the British “pants” means “underwear”, but in the USA “pants” means “trousers”.

Thank you for your replies.

@effigies, I know that the changes are very tiny. It sounds negligible, however registration tools such as elastix and ANTs are sensitive to these small variations in the orientation matrix (as indicated by the ITK colleagues here I’ve perceived intensity variations in contours that may affect consequent segmentation tasks, specially when you’re detecting small structures. I did notice that our Python code uses mostly Nifti1Images from nibabel. I was not aware of the Nifti2Image. Thanks for your advice!

@Chris_Rorden, thank you so much for this detailed explanation of how dcm2niix works. To be honest, I have not used it myself but I’ll definitely explore it a bit more and check compatibility with the tools we currently use.I also liked very much your definition of DICOM and I’ll quote you on that :)! I just hope that Nifti does not become like Spanish, another language with different interpretations in each country/group/tool.