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

[Idea] addition to the wiki about wrong labels on images #59

Open
julfou81 opened this issue Jun 11, 2021 · 15 comments
Open

[Idea] addition to the wiki about wrong labels on images #59

julfou81 opened this issue Jun 11, 2021 · 15 comments
Labels

Comments

@julfou81
Copy link
Contributor

julfou81 commented Jun 11, 2021

Hi @pcklink @niksirbi ,

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:
Capture d’écran 2021-06-11 à 10 28 43

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!

Image Pasted at 2021-6-9 08-09

Do you think it is a sound procedure?
Do you think I should add this in the wiki?

Thank you for your answer!

@julfou81 julfou81 added the Idea label Jun 11, 2021
@niksirbi
Copy link
Member

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.

@pcklink
Copy link
Member

pcklink commented Jun 11, 2021

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.

@julfou81
Copy link
Contributor Author

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).

@julfou81
Copy link
Contributor Author

Thank you also Chris! Yes I have editing rights.I will write with this cautionary note.

@niksirbi
Copy link
Member

niksirbi commented Jun 11, 2021

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.

@julfou81
Copy link
Contributor Author

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?

@julfou81
Copy link
Contributor Author

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.

@niksirbi
Copy link
Member

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
Screenshot from 2021-06-11 12-37-19

@julfou81
Copy link
Contributor Author

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!

@julfou81
Copy link
Contributor Author

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:

Capture d’écran 2021-06-11 à 13 35 46

After:
Capture d’écran 2021-06-11 à 13 35 35

@niksirbi
Copy link
Member

This is fantastic @julfou81 ! Thanks for zeroing on the problem. We should definitely include this knowledge in the wiki now!

@julfou81
Copy link
Contributor Author

Thank you @niksirbi for showing the mri_convert command!

@pcklink
Copy link
Member

pcklink commented Dec 8, 2021

Anyone willing to add a section to the wiki, or did that already happen?

@julfou81
Copy link
Contributor Author

julfou81 commented Dec 8, 2021

My bad @pcklink , I am supposed to do it and got side-tracked. I will do it very soon.

@pcklink
Copy link
Member

pcklink commented Dec 8, 2021

No rush. I was just scrolling through the issues as a reminder of things initiated but perhaps not completed 🙂

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

No branches or pull requests

3 participants