Unable to stop reorientation to LPI

[blakedewey]

What options are available to preserve the DICOM orientation when converting to NIFTI?

[neurolabusc]

dcm2niix uses the NIfTI spatial orientation matrix (SForm) and Quaternion (QForm) to store the orientation information for the volume. There are no options: spatial orientation is always preserved. It should be noted that for 2D sequences (e.g. EPI) the slices are stored to disk in the same orientation as they are acquired (which is required by all the slice timing tools I have seen), whereas for 3D sequences (e.g. T1-MPRAGE) the volume to the closest orthogonal alignment for with an identity matrix (making it simpler to write a viewer to display the data). In both cases, the spatial orientation and slice position is preserved in the NIFTI orientation fields and the image data is copied losslessly.

The only real exception to this rule is CT scans, where the slices can be acquired skewed and with variable inter-slice distances. In this case the software will generate interpolated data as the NIfTI header requires a single uniform distance between slices and most tools can not deal with a skew stored in the SForm. https://www.nitrc.org/plugins/mwiki/index.php/dcm2nii:MainPage#Special_Considerations_for_Computed_Tomography_.28CT.2C_CAT.29

[blakedewey]

So why are the DICOMs for my axial scans presented as RAI, whereas the converted NIFTI files present a LPI orientation? Maybe I misspoke. I am talking about the cardinal orientation (axial, saggital, coronal). In the dcm2nii command, I could switch off FlipY.

[neurolabusc]

Just remember that DICOM and NIfTI have different default orientations http://nifti.nimh.nih.gov/nifti-1/documentation/faq#Q14 I think this is a legacy of NIfTI being based on the older analyze format where the images are drawn on cartesian coordinates (e.g. for each slice the data begins at the bottom of the screen, with the Y-axis ascending as you go up), while the DICOM convention is similar to how we write English, with the first line at the top and the y axis ascending as you go down.

Regardless, the transform is always stored by the S and Q Form.

[neurolabusc]

You can always fork my software and edit main_console_batch.cpp or main_console.cpp to invoke the FlipY option. The snippet below would do it for the main_console.cpp. You would want to test this out, but it should flip the image, the header spatial transforms and the DTI bvec's. I have not exposed this option because it does not seem helpful (as the transform stores the correct orientation), I think to many superfulous options become daunting for users, and I have not fully tested all combinations to validate this.

} else if ((argv[i][1] == 'r') && ((i+1) < argc)) { i++; if ((argv[i][0] == 'n') || (argv[i][0] == 'N') || (argv[i][0] == '0')) opts.isFlipY = false; else opts.isFlipY = true;

[neurolabusc]

Alternatively, you could fork my software and edit the default behavior in nit_dicom_batch.cpp. Simply change opts->isFlipY = true; to read opts->isFlipY = false; the row order will be swapped compared to the normal version of my software, but any tool that is aware of the NIfTI spatial transforms should see them as the same.

[halfSpinDoctor]

Hi Blake,

What viewer are you using?

Some viewers read the header then reorient the images to a specific view (e.g. RAI, etc). Examples of this behaviour would be PACS-like viewers such as Osirix or Horos, as well as the new FSL viewer FSLEyes.

In contrast, older viewers such as FSLview will simply display the image as it is logically written out in the array (which, as Chris mentioned, is copied losslessly from the data portion of each DICOM slice), and then apply L/R A/P H/F labels post-hoc based on what the header reports.

Hope this is helpful.

With best regards, Sam

On 1 June 2016 at 11:25, Blake Dewey notifications@github.com wrote:

So why are the DICOMs for my axial scans presented as RAI, whereas the converted NIFTI files present a LPI orientation?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/neurolabusc/dcm2niix/issues/26#issuecomment-223047804, or mute the thread https://github.com/notifications/unsubscribe/AJliZSjVYoJ-_MjkPfJpREVy9-vftZTBks5qHbKAgaJpZM4Irtuj .

[blakedewey]

Sorry for the late reply. I normally use MIPAV, which by default shows the data as it is written on disk. I was also working with some software that was not sensitive to the header information and required the data to reflect its header orientation. It is not a big concern, just a curiosity, as mri_convert and Dimon both preserve the DICOM orientation on disk. This can be worked around easily by running 3dresample after dcm2niix.

[neurolabusc]

Yes, there are two approaches: one is to save the DICOM data precisely as it is recorded, so there are minimal changes. The other approach is to flip the order of the rows because DICOM defines rows as being ordered from top to bottom (just like we read text, with the first line at the top), whereas the NIfTI format specifies the first row is at the bottom of the screen (just like cartesian graphing coordinates). Unfortunately, viewers that ignore the spatial transform are inconsistent on which pattern they use (I seem to recall the behavior of the popular ImageJ drove my initial choice). As I noted, my software gives you the "isFlipY" option.

Why not make a feature request and ask the MIPAV team to rotate the image to the nearest orthogonal by default (like my MRIcroGL does)? This is lossless and reduces the chance of left/right confusion. If the developers are familiar with Matlab, they can look at Xiangrui Li's dicm2nii, or if they prefer C they could use my code https://github.com/neurolabusc/MRIcro/blob/master/MRIcroX/nii_ortho.cpp Note this is perfectly safe for a viewer, but for storing data to disk you want to be careful about slice order for time-series (fMRI/resting state) so you do not confound slice timing correction.