Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is it possible to manipulate the orientation parameters? #117

Closed
xfgavin opened this issue Jul 17, 2017 · 1 comment
Closed

Is it possible to manipulate the orientation parameters? #117

xfgavin opened this issue Jul 17, 2017 · 1 comment

Comments

@xfgavin
Copy link

xfgavin commented Jul 17, 2017

For example, I would like to have my converted image to be in LPS orientation not in LAS.
Thanks.

@xfgavin xfgavin changed the title Is it possible to manipulate the *_ras orientation parameters? Is it possible to manipulate the orientation parameters? Jul 18, 2017
@neurolabusc
Copy link
Collaborator

In theory you can edit nii_dicom_batch.cpp and change the line opts->isFlipY = true; to read opts->isFlipY = false; and recompile. This will change the order of the rows as written to disk. However, the purpose of this line is to emulate other DICOM converters, and not to ensure LPS vs LAS convention. For all 2D images my software will preserve the slice orientation as saved to disk in the DICOM file, therefore while rows are the P-A dimension for axial acquisitions they are the I-S dimension for coronal and sagittal scans. This is required for slice timing tools. If my software detects that an image is a 3D acquisition, it will reorient the volume to the closest orthogonal rotation to an NIfTI identity matrix [1,0,0; 0,1,0; 0,0,1] (though note many tools store their templates with the left-right reversed, e.g. [-1,0,0; 0,1,0; 0,0,1]).

In all cases, my software strives for lossless copying of raw image data (no interpolation) and the spatial transforms are stored in the header s-form and q-form. If you want to reorient your images, you can use fslreorient2std - though my caveats regarding slice timing should be considered. A much better solution is to let the viewing software take care of the rotations for you. This can optionally include lossy reorientation that gets the image aligned nicely without degrading the quality of the stored data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants