[Idea] addition to the wiki about wrong labels on images
julfou81 opened this issue · 15 comments
I would like to report a procedure that we use now in our lab to correct for the wrong label issue in some NHP acquisitions (like when the animal is in sphinx position, or that there is any kind of mismatch between the registration at the subject on the scanner and the actual position of the animal in the scanner).
Here is an example:
The solution we use now lies in in two lines using AFNI and FSL: The labels are wrong so don't look at them. First you need to look at the data storage (in FSLeyes for example) (you have to determine toward each direction each dimension is increasing):
- 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 -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
=> the image is now ready to work with!
Do you think it is a sound procedure?
Do you think I should add this in the wiki?
Thank you for your answer!
Hi Julien, this seems like a smart solution, and I see no reason for it not to work universally.
As far as I understand, the only requirement is that you know which way is up, front, and left-right. The first two are obvious, the last one is sometimes impossible to know unless you have a marker (but this problem applies to every other reorientation hack as well).
I happen to have some misoriented monkey data, so I will give this method a try right away and let you know how it works.
And yes, I think this definitely deserves to be on the relevant section of the wiki.
I agree. You have wiki editing rights, right? Just add a section. I'd suggest you present as you did here, that this solution works in your lab (perhaps @niksirbi can add a nudge if he confirms it on his data) so readers know it hasn't been tested on an extensive range of different datasets (even though I don't expect problems either). This is what the wiki is for: if people find that it doesn't work for them, or see ways to improve we can always adjust.
Thank you Niko for your fast answer! Yes you are right, R-L is always very tricky and without a marker it may be difficult to know which is which. If you happen to know how the animal was registered at the console and how it was actually positioned in the tunnel, you may guess how wrong is the label. It happened to us recently:
The marmoset (with no pastille on the right temple) was registered "head first - supine" but was actually positioned feet first - supine in the magnet. In that case the labels are wrong in the following way: x and z axis are flipped, meaning that the L label in the image viewer is actually the right side of the monkey's head. In that case when you look at which direction the cursor is moving to, you can guess that if the cursor in moving to the 'L' label in the viewer, it is actually moving toward the right side of the monkey and the data storage is then 'R' for this dimension (FSL convention).
Thank you also Chris! Yes I have editing rights.I will write with this cautionary note.
You are completely right about the LR thing. Just trying to think through your example gave me a headache :). Plus, sometimes we don't know how the animal was registered during scanning. Markers are the only fail-proof way.
Meanwhile, I did some testing of your method. I loaded a misaligned macaque T1 image into fsleyes, and determined that the data orientation was RIA (x, y, z displays were increasing towards right, inferior, and anterior respectively). Then I ran: 3drefit -orient LSP my_image.nii.gz, followed by fslreorient2std my_image.nii.gz my_reoriented_image.nii.gz. This didn't help, the reoriented image was identical to the original. After some digging, I found that the problem was the 3drefit command: it was not resetting the orientation labels (which I could verify running 3dinfo my_image.nii.gz before and after 3drefit). So instead I tried mri_convert --in_orientation RAI my_image.nii.gz my_converted_image.nii.gz, followed by your fslreorient2std command. This actually did the trick! The correct image came out, with standard orientations and label. Trying mri_convert with LSP gave the wrong results, which I guess means that freesurfer uses the same convention as fsl?
Anyhow, I don't know why 3drefit doesn't work for me. It runs without errors, but it doesn't have any effect on the image or its header. Maybe you can include the mri_convert option as as an alternative in the wiki, for people that might encounter the same.
ok! Thank you for checking! Would you mind sharing the file you wanted to correct to see if it something to do with your AFNI or with the file itself? or maybe just share the output of 3dinfo for this image?
I can confirm that freesurfer uses the same convention as FSL: https://surfer.nmr.mgh.harvard.edu/fswiki/mri_convert
Eg, if the volume is axial starting inferior and going superior the slice is oriented such that nose is pointing up and the right side of the subject is on the left side of the image, then this would correspond to LPS, ie, as the column increases, you move to the patients left; as the row increases, you move posteriorly, and as the slice increases, you move superiorly.
Sure! You can download the file from here: https://drive.google.com/file/d/1B8vq7V1N6KEC151YT3zYCBy4cvS7BGSh/view?usp=sharing
It's the original, unaltered nifti. You can assume that the R label is correct.
Below is a screenshot from the 3dinfo output before and after 3drefit
It is also very good to know that this works also with freesurfer, it can be useful for users who don't use AFNI on their system!
Thank you for sharing! It was a perfect counter example! I also got a headache when I discover that AFNI 3drefit did not do anything to this file. I tried many thing, convert the nifti file to AFNI format, delete orientation before...
Finally I found the solution: your dataset is oblique according to AFNI, so the command that works is:
3drefit -deoblique -orient LSP sub-10_T1w_orig.nii.gz
Before:
After:
This is fantastic @julfou81 ! Thanks for zeroing on the problem. We should definitely include this knowledge in the wiki now!
Anyone willing to add a section to the wiki, or did that already happen?
My bad @pcklink , I am supposed to do it and got side-tracked. I will do it very soon.
No rush. I was just scrolling through the issues as a reminder of things initiated but perhaps not completed 🙂