align_anat_epi.py settings and warnings

AFNI Message Board
1

Hi there,

I am using align_api_anat.py under afni_proc.py for some alignment of epi (partial coverage) to an anatomical

I am getting some warnings with my first pass (code below), and just wanted to make sure I am doing the right things.

The first warnings are about obliquity.

I get obliquity warnings about my epi (around 36 degrees from plumb) during most parts of the processing (3dToutcount, 3dAutomask, 3drefit, 3dAllineate etc.)
I also get two obliquity warnings about my anatomical (about 2 degrees from plumb) during 3dAutomask and 3dAllineate

The anatomical warning is a bit weird because 3dinfo says it is not oblique at one point in the output:

3dinfo ./__tt_FR_uniden_avg_ns+orig | \grep ‘Data Axes Tilt:’|\grep ‘Oblique’
#++ Dataset /scratch/inode/uqhdemp1/P007_playing/P007_FR_6.results/__tt_FR_uniden_avg_ns+orig is not oblique
#Script is running (command trimmed):
3dinfo ./pb00.P007_FR_6.r01.tcat+orig | \grep ‘Data Axes Tilt:’|\grep ‘Oblique’
#++ Dataset /scratch/inode/uqhdemp1/P007_playing/P007_FR_6.results/pb00.P007_FR_6.r01.tcat+orig is oblique*

From what I can tell, because I am using align_epi_anat.py, it works out I have obliquity and includes this in the alignment. I can see obliquity transformation in the output for 3dAllineate.
Q: is it dealing with the obliquity, so I don’t need to worry/ do anything further?
Q: Does it deoblique the epi, or the anatomical, or just aligns them to each other so you don’t need to worry about obliquity?

In a later round of processing, I included -deoblique as an option in align_epi_anat.py (see second pass code), but I still get the warnings.
Q: Do I need to bother including this -deoblique if it is seemingly doing it anyway in align_epi_anat.py?

[I am aware I can turn the warnings off if I like by editing my .afniric file]
[Alignments appear to be good - and no difference with -deoblique on or not specified from what I can tell visually]
[I am aware they are just warnings, not errors]

The second warnings are about autoweight

I have not specified my cost function in align_epi_anat.py and seems to be using the default -lpc. I get the following warning about using autoweight

‘-autoweight’ is recommended when using -lpc or -lpa #
++ # If your results are not good, please try again

The info in 3dAllineate -help looks like you need to specify numbers to say how you want the autoweight to be computed…? I don’t really know what I should be doing here, so would not know what numbers to specify…

I tried putting -autoweight on its own as an option in align_epi_anat (see third pass code below) but does not run (brings up an error).
Q: I guess my question is, should I be using autoweight? If so, how do I add it as an option?

The third warning was about cmass

My align_epi_anat produces three 3dAllineate blocks

  • The first is e2a alignment only, this appears to use cmass+a
  • The second combines e2a and oblique transformations to make my new warped anatomical without skull → this is where I get the following warnings

[7m*+ WARNING: [0m center of mass shifts (-cmass) are turned off, but would be TERRIBLY large!
[7m*+ WARNING: [0m - at least one is more than 50% of search range
…
[7m*+ WARNING: [0m -cmass was turned off, but might have been needed :frowning:
please check your results - PLEASE PLEASE PLEASE

Q: Do I need to add cmass option into my code? (presumably cmass+a if do, due to partial volume)
Q: I tried putting the option in as -cmass+a but this did not work, so I put -cmass cmass+a (see fourth pass code). Is this wrong?

[Note: I ran the third pass code and still get warnings about cmass being turned off in the second 3dAllineate…]
[Also, the help options suggest I am already getting cmass shifts with ginormous_move, which might be why I see cmass+a in the first 3dAllineate block… so maybe I don’t need to change anything?]

Sorry about having so many questions, I am a major noob to all things fMRI. This is literally my first analysis :o

Thank you for your time,

Harriet

First pass code.

afni_proc.py -subj_id $subj
-blocks align
-dsets $data_dir/P007_FR_RUN*
-tcat_remove_first_trs 0
-copy_anat $data_dir/FR_uniden_avg
-anat_has_skull yes
-align_opts_aea
-ginormous_move
-partial_coverage

Second pass code

afni_proc.py -subj_id $subj
-blocks align
-dsets $data_dir/P007_FR_RUN*
-tcat_remove_first_trs 0
-copy_anat $data_dir/FR_uniden_avg
-anat_has_skull yes
-align_opts_aea
-deoblique on
-ginormous_move
-partial_coverage

Third pass code
afni_proc.py -subj_id $subj
-blocks align
-dsets $data_dir/P007_FR_RUN*
-tcat_remove_first_trs 0
-copy_anat $data_dir/FR_uniden_avg
-anat_has_skull yes
-align_opts_aea
-deoblique on
-ginormous_move
-partial_coverage
-autoweight

Fourth pass code
afni_proc.py -subj_id $subj
-blocks align
-dsets $data_dir/P007_FR_RUN*
-tcat_remove_first_trs 0
-copy_anat $data_dir/FR_uniden_avg
-anat_has_skull yes
-align_opts_aea
-deoblique on
-ginormous_move
-partial_coverage
-cmass cmass+a

2

These are all pretty normal messages. aea typically takes care of obliquity except for the ginormous option when it’s not as important anyway. The center alignment of the ginormous option is implemented instead of the oblique transformation. aea takes care of both the weighting and the cmass options, so neither should be necessary.

3

Hi Daniel,

Thanks for getting back to me

Looks like I will ignore the -obliquity -autoweight and -cmass options, as it is likely they are already being accounted for in my script.

I can see where deobliquing is taking place, and where cmass+a is being used in the output script, but no mention of -autoweight at all.

Question: Does this mean it is not being used, but is not needed?

Second question: If I were to add -autoweight into my script, how would I use it? (I could not tell from the details in the 3dAllineate -help) -autoweight on its own as an option for align_options_aea errors and does not run.

Again, very much appreciate you taking the time to help me!

Harriet

4

aea generates its own weight dataset, hence the lack of autoweight. If you need this or a different weighting, you may want to call 3dAllineate separately with similar inputs, or I would have to add a separate option for this to make aea aware of this.

5

Hi Daniel,

Thanks for your reply.

I think I will also leave the autoweight option alone: I don’t have a specific autoweight setting in mind I wanted to use, I was investigating whether it could improve alignment (in light of the warning aea threw up).

Basically, I think my epi-anatomical alignment is ok (I am unsure if it is close enough as I am new to fMRI), but would love any tips on things I can try to improve it.

I have tried changing the cmass, deobliquing options within aea - all to no effect as they are, as we discussed, being taken care of by aea.

I also tried using lpc+ZZ instead of lpc as the cost function, but this produces a catastrophically misaligned epi-anatomical. Not sure what I did wrong there (code below). The anatomical is clipped, so I tried zero padding it before running, but this did not work either.

Any tips to get lpc+ZZ to work, OR other suggestions to try improve alignment would be very appreciated.

Thank you for your patience,

Harriet

code:

afni_proc.py -subj_id $subj
-blocks align
-dsets $data_dir/P007_FR_RUN*
-tcat_remove_first_trs 0
-copy_anat $data_dir/FR_uniden_avg
-anat_has_skull yes
-align_opts_aea
-cost lpc+ZZ
-ginormous_move
-partial_coverage

6

As a possibly related update - when I try and do volume registration with 3dAllineate using lpa+ZZ I get good registration but really weird clipping of the brain where, as I move to more sagittal slices, the front of the brain completely disappears (looks like a big black shape is moving from forward to back over the brain until you can’t see it anymore).

So, alignment and volreg have issues when I try to use +ZZ…

Could this be because I have partial coverage? (though, this is noted in aea)

Thank you for your help

Volreg code (alignment code in previous comment)

afni_proc.py -subj_id $subj
-dsets $data_dir/P007_FR_RUN*
-tcat_remove_first_trs 0
-blocks volreg
-volreg_align_to MIN_OUTLIER
-volreg_method 3dAllineate
-volreg_allin_cost lpa+zz
-volreg_warp_dxyz 0.8
-volreg_motsim

7

My guess is the partial coverage is a big part of the problem. If the coverage is very limited, and there is little structural information, then alignment is more difficult. That applies to both the EPI motion correction and to anatomical-EPI alignment. Very few users will use the volreg method of 3dAllineate for partial data. It’s usually more useful for datasets that can distort more across time. If your data is distorted between runs instead, then consider “-volreg_post_vr_allin” to align across sessions with 3dAllineate. You will typically want both align and volreg blocks in your processing.

The lpc and lpc+ZZ cost functions require inverted tissue types between the two datasets, so CSF is bright in one and dark in the other usually. That is typically the case for anatomical to EPI alignment. That contrast can be more difficult to have in a small piece of brain, depending on where in the brain you’re looking and the acquisition protocol parameters. The lpa, lpa+ZZ, nmi, cru and ls cost functions typically work better for these low-contrast datasets and for motion correction. The same would apply for volumes that are similar as in the case for the volreg motion correction. Alignment of a dataset will take the dataset out of its original acquisition plane of course, so there will be partial slices as you move towards the edge of your EPI dataset. Usually that’s pretty limited though, but it could be important for a very partial dataset.

8

Hi Daniel,

Thanks for your response. Sounds like issue with alignment using lpc+ZZ is related to partial coverage, as you say, so will leave it and use lpc, which worked ok.

Back to volreg for a second, when I use MIN_OUTLIER volreg, there is quite a lot of motion left only in my first run (all others are much improved, see image 1 below).

Image 1 – enorm for original data (black) vs. enorm after volreg (red)

https://i.postimg.cc/J4v485DH/Image1.png

Do you have any advice for this kind of case, where there are problematic levels of motion, but only in one run? Should I try doing MIN_OUTLIER volreg on run 1 again on its own? (i.e., a second volreg of the same kind for this run only). Or do a second volreg for run 1, but using a different method? Would there be an issue doing later steps (like regression) with runs of slightly different smoothing extents (as could be introduced by different pre-processing)?

I have tried volreg_post_vr_allin which registered all runs really well, but it introduces smoothing to the epi’s, which I am trying to avoid as much as possible.

With regards to the epi clipping when I did volreg with lpa+ZZ, I have attached an image (see image 2 and image 3). Does this look like the clipping you were talking about, i.e., that you would expect because things have been moved around? Or does it look more sinister?

Image 2 – pb.00.tcat.r01 (left) vs. pb.01.volreg.r01 (right), spatially matched – view 1 (most sagittal)

https://i.postimg.cc/7ZzPZJ0s/Image2.png

Image 3 – ‘’ (a bit more lateral)

https://i.postimg.cc/g0PzXcKY/Image3.png