Always use Giant_Move - is this a problem?

AFNI version info (afni -ver):

25.0.00

Hi Afni GURUS -

Small but important question that I haven't been able to answer on my own -

We want to run multiple afni.proc's in a batch file for a lot of participants. For some of these - we will probably have to use the flag giant_move to correct alignment issues, but for some it won't be needed.

Instead of running everyone w/o giant_move - and then checking the QC results, and deciding which will be better if giant_move is run apriori - is it a problem to just run giant_move for everyone in advance? Will that hurt our results? In what way is that problematic?

Thank you!

For most data, this will be fine. The giant_move opens up the parameter space for translation,rotation and scaling. That can backfire if the data has poor tissue contrast. From the scanner, the EPI and the anatomical data are normally very close, so giant_move is not required at all. There is a section of the align_epi_anat.py help that goes into all the related options: -big_move, -large_move, -giant_move, -ginormous_move. In the end, you will need to visually check for alignment, probably with the QC pages at least.

In addition to Daniel's sage advice, I would note that:

  • I have often left -giant_move in as an option, even if the EPI-anatomical data are pretty well aligned from the start, just as a generalization, since there is a larger parameter space of alignment parameters to work through.
  • From July, 2025 (so more recent than your AFNI version), there is a newer variant of that called -large_move that might be my new go-to, because it doesn't include a center-of-mass alignment at the start. In general, human MRI datasets tend to have more reasonable coordinates than in some of the earlier days, so the EPI and anatomical coordinates are often consistent from within the same session, and a center-of-mass pre-alignment is not needed to come in to restore sanity from an odd coordinate setup. This will esp. be the case if you have "slab" or otherwise non-whole brain datasets involved (either EPI or anatomical).
  • That being said, probably -giant_move is still reasonable in many cases of mostly whole brain datasets, because we often skullstrip the anatomical with sswarper2 before processing.

Additionally, with human FMRI processing, I tend to always include:

-align_unifize_epi local

nowadays, to help overcome any potential EPI brightness inhomogeneity issues. Similar to the above, I just include it in all human FMRI processing, because I have generally only seen it help alignment or not harm it, depending on the amount of EPI inhomogeneity that is present.

Some more discussion of these and other tips+tricks are provided here, too:

  • Reynolds RC, Glen DR, Chen G, Saad ZS, Cox RW, Taylor PA (2024). Processing, evaluating and understanding FMRI data with afni_proc.py. Imaging Neuroscience 2:1-52.
    https://doi.org/10.1162/imag_a_00347

... and certainly happy to chat more about other options.

--pt

As usual - thank you so much for these extremely helpful responses.

I'll check out -large_move.

Thanks again