I have a problem with MRIs I downloaded from the OASIS project. The images acquired with one of the scanners seem to have incorrect orientation informations because when I use mri_info on the images, I get warnings saying that “neither NIfTI-1 qform or sform are valid” and the orientation field gives “???”. Due to this problem, I actually can’t apply fslreorient2std on these images because it can’t find the orientation information.
I would like to find a solution for this problem. Maybe I can fix the orientation by myself in the nifti files, but it doesn’t seem to be simple.
If when you display the image in FSLeyes for instance the labels are wrong or not present, here is a procedure we use with Non Human Primate images:
The solution lies in in two lines using AFNI and FSL: First you need to look at the data storage (in FSLeyes for example) (you have to determine toward each direction each dimension is increasing):
If for instance:
- in x, the cursor is going toward the neck when x increases: I (Inferior)
- in y, the cursor is going posterior when y increases: P (Posterior)
- in z, the cursor is going left (opposite to the pastille), when z increases: L (Left)
=> The data storage is ‘IPL’ in FSL convention, and ‘SAR’ in AFNI convention (opposite convention between AFNI and FSL, why keep things simple? )
So the first command is from AFNI:
3drefit -deoblique -orient SAR your_image_to_correct.nii.gz
=> the label are now correct but the display is not standard in FSLeye
So to have a correct display, we now use FSL:
fslreorient2std your_image_to_correct.nii.gz your_image_corrected.nii.gz
You can also use MRIcroGL to resolve this graphically. Choose Import/Tools/Rotation. It will guide you to sequentially select the axis that best represents Left/Right, Anterior/Posterior, Inferior/Superior. It re-slices the data to canonical NIfTI space, so it is probably not a good choice for EPI data where you want to apply slice time corrections (though human EPI sequences are typically axially acquired, in which case this method works).
Missing or incorrect coordinate information is an important and all too common problem in FMRI/MRI data. With this kind of problem you have posted here, I typically do something that’s a combination of jsein’s and Chris_Rorden’s approaches. If you know the storage orientation, then you can skip most of these steps and just use 3drefit, but most of the time, I’ve found that is not the case. If the data is viewable but in a weird, wrong direction (orientation is upside down for instance), then follow these steps:
copy data to an uncompressed format
3dcopy mydata.nii.gz mydata
Note data type and number of voxels in i,j,k (columns, rows, slices) directions.
Read data with to3d
In to3d GUI, preview images to show slices as they are stored on disk. The slider at the bottom of the image window shows each slice in the stored volume.
In upper left of GUI, note directions across screen, down screen, increasing slices. Each of the first letters of those directions from start to end direction gives the orientation in AFNI terminology. For example, if the image goes from Right-to-left across the image, Anterior-to-posterior down the image and Inferior-to-posterior with increasing slices, then the orientation is “RAI”. Note the orientation and leave the GUI without saving.
Refit the orientation of the data or the copy.
3drefit -orient RAI mydata.niii.gz
What this procedure does not do is preserve any oblique information in the data. We have also pointed out in the past that the left and right are typically not easy to distinguish because most brains are symmetric enough to make generalizations difficult to establish. This is unfortunately common (see link below). We do have a test for left-right flipping as a check_flip option in align_epi_anat.py that we typically recommend calling through afni_proc.py. This test works by comparing two datasets, typically EPI and anatomical datasets, to see if there is an inconsistency.
If I can find some time, I’ll try to make a short video of the to3d method to determine orientation.