Is my data really oblique?

AFNI Message Board
1

Dear Afni experts,

I am a new user of Afni and I am using it for analyzing rs-fMRI data.

I was getting warning messages about obliquity of data, and alignment between anat and EPI was miserable. I have tried a few things and they have worked, but I am not sure which one is the best option and why?

This is what I have tried:

1- I used 3dwarp on anat alone and then on anat and EPI both before running the afni_subject.py, and it improved the alignment in both cases.

2- I used 3drefit on n anat and EPI both, and alignment was no better than that in 1.

3- I used giant_move only and alignment is quite the same as in 1.

Now, I am confused. I am not sure where the actual problem is. Is it that the subject moved between the two scans (which is dealt with by giant-move), or that there is real obliquity (fixed by 3dwarp) or that there is bad metadata (fixed by 3drefit)? Please help.

Thanks

2

My guess is that there is no problem here. If the data is oblique, then you can do any of these steps

  1. Warp one dataset to match the other - this doesn’t explicitly align the data, but they should appear to be roughly aligned in the afni GUI.
  2. Deoblique both datasets or just the oblique dataset. If the origins are the same, then that should also show close alignment.
  3. Align the original data with align_epi_anat.py or with afni_proc.py. That will automatically include the obliquity transformations to match one dataset to the other and compute an alignment too. Both transformations and motion correction transformations will be combined. That helps reduced smoothing from multiple interpolations.
  4. Ignore or remove the obliquity information and align with a -giant_move or even -ginormous_move. Because the alignment allows for large distances and up to 45 degree rotations, oblique datasets can be aligned without more information. For datasets with good structural contrast in the EPI data, this works well, and it’s often useful for datasets with questionable or missing NIFTI headers.

You can examine a specific dataset with 3dinfo to see if it is considered oblique. Again warnings are just warnings. If you’ve taken these into account using one of the methods, then you’re most likely fine. You can turn off or limit warnings in the afni GUI with the environment variables, AFNI_NO_OBLIQUE_WARNING and AFNI_ONE_OBLIQUE_WARNING. It’s easiest to set those in your ~/.afnirc file. There is a brief description of obliquity handling here:

https://afni.nimh.nih.gov/sscc/dglen/Obliquity

3

Thank you for the reply, Daniel.

I am wondering if I can send you my processed data (the final anat and all_runs epi) for a quick check. The volumes seems to be aligned well. There is however a few instances where the edges of the epi slices seem to be smaller in size. I am not sure where is this coming from and if it is curable.

Eyesha

4

Hi Eyesha,

If you want to upload such data, upload a new
directory (tgz file) containing copies of:

  • original anat
  • anat_final*
  • vr_base*
  • final_epi_vr_base*

along with copies of the text files:

  • afni_proc.py command
  • resulting proc script (e.g. proc.SUBJ_ID)
  • text output from proc script (e.g. output.proc.SUBJ_ID)

Also, if your AFNI version is current, you can post
an image showing the alignment result on the
message board using @snapshot_volreg, e.g.
using the AFNI_data6/FT_analysis results:

@snapshot_volreg anat_final.FT+tlrc final_epi_vr_base+tlrc FT

For this, please see Bob’s MB post.

  • rick
5

Hi Rick,

Many thanks for help.

I just uploaded the file Eyesha.tgz, which hopefully has all the data that you would need to run a check.

I am very interested in using the hot-off-the-grill @snapshot_volreg, and I updated my AFNI just now, but I get the following error message:

My command: @snapshot_volreg anat_final.acu0023+tlrc all_runs.acu0023+tlrc acu0023_A2E

Message: ** ERROR: pnmcat pbmtext pamcomp pamstretch pbmtopgm – not found in path – @snapshot_volreg fails

I am wondering if you, or someone would be able to resolve this as well.

Many thanks,

Eyesha

6

Those are some of the netpbm tools.
What OS are you using?

  • rick
7

Hi Eyesha,

Those volumes seem to be well registered. Note
that the anat shows internal motion and the EPI is
only around 3x3x5 mm resolution. But even so,
the result looks pretty good to me.

Did you run @ss_review_driver, and follow its
instructions to review the alignment?

  • rick
8

Hi Rick,

Thanks for your help.

Yes. I did notice the motion in anatomical. And this is the EPI resolution that we have.
I do run the @ss_review_driver but as I am a beginner, I thought I would double check my processing.

I noticed what seems like a little bit of clipping of EPI…it is obvious in some slices in EPI in the coronal plane (I think slice 89 is the best example). I looks like that EPI slice is shorter and does not cover the inferior aspect of the anatomical. I am wondering where is this coming from.

Aside, I have OS X Yosemite, 10.10.5. Are there any versions of the netpbm tools compatible with my OS?

Many thanks for your help again.

Eyesha

9

Hi Eyesha,

For the clipping, do you mean at the bottom of the
cerebellum? If so, that little bit is probably due to
subject motion.

If it is in a different area, please provide coordinates,
and maybe the part of the brain that it is close to
(e.g. via “Where Am I?”).

Regarding the netpbm tools, I will try to find out.

  • rick
10

Hi Rick,

It is bilateral. Check for example:

TLRC coordinates: -51, -9, -31 and 44, -9 -41 (Inferior temporal gyrus)

Thanks,

Eyesha

11

That is a little bit of signal dropout (i.e. lower signals
in the images acquired at the scanner), which is very
difficult to avoid. It is in the original images, too, and
is not due to processing.

  • rick
12

Thank you.

Eyesha