Hi,

I don't want any reorientation or origin changing of my dicom images when converting to nii, but dcm2niix seems to do so automatically. Is there a way to prevent this?

Thanks very much,

- Angela

In brief, dcm2niix losslessy preserves the voxel data. Be aware that DICOM and NIfTI use different spatial coordinates, and these transforms are typically encoded in the SForm and QForm of the data. The software does not reorient all images to RPI. Spatial manipulation depends on the input.
 https://www.nitrc.org/plugins/mwiki/index.php/dcm2nii:MainPage#Spatial_Coordinates

For 3D scans (e.g. MP-RAGE) it does re-orient to the nearest orthogonal to a NIfTI identity matrix, with the residual angulation saved in the SForm and QForm. You can disable this by commenting out the line 
   imgM = nii_setOrtho(imgM, &hdr0);
to read
   //imgM = nii_setOrtho(imgM, &hdr0);
I would also comment out the lines nii_saveCrop line in a similar fashion.

For non-3D sequences, the image row order is flipped. For sagittal and coronal scans this is the head-foot dimension, for axial scans this is the anterior-posterior dimension. Again, any change is encoded in the NIfTI header. The reason here is that the convention of DICOM and NIfTI is to store rows in the opposite order: in DICOM row number increases from top to bottom, like we would write a numbered list in english. In NIfTI, row increases toward the top of the page, as we would draw the Y coordinate on a cartesian grid. You can change this with
  opts.isFlipY

Finally, dcm2niix enforces that data is saved such that the first three dimensions are contiguous spatial dimensions while time is the fourth dimension. This is required by NIfTI and can not be changed. DICOM is much more flexible in this regard: the data can be stored to disk in any order (e.g. the jumbled order that slices come off the reconstructor, the order scans were acquired which would jitter the spatial dimension for interleaved acquisitions, etc). 

The origin never changes its spatial location, though it changes its coordinate system from DICOM to NIfTI. For MRI the origin is isocenter, for CT it is table center. Often, origin is the first thing you will want to change AFTER conversion - setting this to a location near the anterior commissure to provide a good starting estimate for normalization. dcm2niix does not do this for you. I use the script nii_setOrigin() to do this with my MRI data.

For your purposes, you may be better served by a different image converter. I list alternatives on the 
  https://github.com/rordenlab/dcm2niix
and
  https://www.nitrc.org/plugins/mwiki/inde... 

Dear Chris,

Thank you very much.

I would like to try dcm2niix with opt.isFlipY turned off, as well as disabling the reorientation. Where is this code? Do I need to build from source?


Thanks,

- Angela

The code is on Github.

With a Linux/Mac set up for development (git and C compiler installed) you should be able to download and compile with the commands:

git clone https://github.com/rordenlab/dcm2niix.gi...
cd dcm2niix/console
make

To change the code, simply edit the line
  opts->isFlipY = true; //false: images in raw DICOM orientation, true: image rows flipped to cartesian coordinates
in nii_dicom_batch.cpp to read
 opts->isFlipY = false;
and re-compile. You can likewise edit the orthogonal rotations applied to 3D images.

The COMPILE.md file will provide details if you want to compile on a Windows computer.

Wonderful!!!! Works perfectly. Thanks so much for the help!

- Angela

Hi,

I am having a similar issue. I have T1 images (MP-RAGE, SIEMENS) that were collected Sagittal RL, and when I convert them, the orientation is correct, but when I read them in (e.g. Slicer) then the slices are Axial IS. Keeping them in Sagittal RL is the easiest way to keep my transformation pipeline intact and reference everything to my T1 and B0.


I have changed the things that you suggested in this feed and recompiled the scripts but I still get the change from Sagittal to Axial. I am assuming this is because of the way that the NIFTI files save the data, that the whole system is in RAS or LPS such that the first dimension of the data is right/left etc.

Still, is it possible to change this?

Thanks,

Virginia

Virginia-

 If you go to the dcm2niix Github page and build the developmental branch you will be able to get v1.0.20180220 (or you can just wait for the next stable release). This includes the new "-x i" option that will neither rotate nor crop 3D acquisitions. I would generally discourage the use of this option, as I think lossless rotation is useful and it makes the output more consistent. However, I have added this feature as it seems important to some. 

To clarify the situation, for most human brain studies the 2D EPI sequences (fMRI, DWI, ASL) are acquired in the axial plane. dcm2niix ALWAYS saves 2D series to disk with the same slice order as acquired, ensures slice timing routines work as expected. For 3D acquisitions like T1 MP-RAGE and T2 SPACE, dcm2niix will by default losslessly rotate the image data to match the NIfTI identity matrix (e.g. they are resliced to be axial). The residuals of this rotation are stored in the NIfTI header, so a resliced and unresliced image are identical when viewing with tools that aligned images based on the NIfTI header (MRIcroGL, SPM, FSLeyes etc). However, these 3D images tend to appear much more similar to the typically axially acquired 2D fMRI and DWI sequences when you use other tools like FSLview that do not reslice the data. 

If your transformation pipeline has issues with this, I would carefully inspect the pipeline. The image rotations are stored in both the S-Form and the Q-Form of the NIfTI header. If your pipeline is having problems with these differences, it may also not be accounting for slice angulation differences, differences in image origin and dreaded Left-Right mirror flips. The NIfTI S/Q-Forms often provide exceptionally accurate starting estimates for registration within a series, avoiding local-minima solutions for coregistrations conducted with poor starting estimates. For tools that are aware of the Q/SForm, the images are identical with the "-x i" versus the default solution.