Jacked up overlay when functional atop structural but not when alone

Hi folks,

So I’m collaborating with some folks from Bulgaria who are sending me their fMRI scans. Not the sharpest T1s, but good enough at least for manual landmarking for co-localization. however, when I try to do my usual manual alignment and co-registration (to nudge the structural to match the task time series image in space), the structural data suddenly become horribly mis-aligned and truncated. See pics of native structural as underlay, then again as overlay. What happened and what could be done about this?



P.S. I can upload the two respective files if someone can steer me to the upload URL


Also, in what I suspect is a related bug, when I simply try to @auto_tlrc warp the native structural brain to a skull-stripped version in MNI space, I get a warning that “dataset centers are 63 mm apart.” Truth be told, I’ve been getting massive mis-matches like that between structural and functional scans even in my own collected data that I overwhelm with -ginormous_move in auto-aligning steps. Is there some weird setenv setting that makes my AFNI think that my structural scans are centered somewhere weird?

Hi, Jim-

Well, for most data, I wouldn’t even try manual/landmarking alignment steps. I would let the cost function do your work. There are a lot of features about alignment to note, and many of these are covered in this playlist:
… with the general AFNI Academy lectures homepage here:

I will send you a link to upload an example EPI-anat pair and I can take a look. Typically, we want to estimate the alignment as part of the FMRI processing pipeline, and then have this alignment be concatenated with any other alignment steps (going to standard space, motion correction, phase distortion correction, etc.)—afni_proc.py is very good and very convenient for this.

Picking the cost function appropriate for EPI-anat alignment is also key–typically lpc+ZZ is what we start with for standard EPI and T1w anats.

All alignment is helped by starting “close to” a good solution. If EPI and anatomical dsets are connected in the same session, then their coordinates should be similar and overlap should be good. Having good/reasonable coordinates is always a plus for many steps in alignment. If there is obliquity in either acquisition, they might appear further away from each on in the GUI than their header information actually knows where they should be.

Also, we typically skullstrip the anatomical before alignment—note here how the EPI and anat have very different features, such as the latter having a bright skull, a face, a neck, etc. We don’t want those extraneous bits of non-brain to affect things. We typically include an @SSwarper command prior to running afni_proc.py, and hand over those results to be incorporated in the processing.


Hi Jim,

In addition to Paul’s useful comments, it sounds like you might want to run @Align_Centers on all of the datasets (maybe align to that of your template).

Having centers far from 0,0,0, or far apart between anat and EPI, is often problematic.

  • rick

Hi guys

So both scans were in the same space/session, so alignment should have started from a good place. Interestingly, the SAME image file becomes misaligned in this case only in the CONTEXT of being overlaid atop another image in AFNI viewer space. I am uploading the source images to get to Paul for an examination.

In general, for years, despite always collecting my T1 structural in the same session and head positioning as task-fMRI when I do align_py kinds of coregistration steps, AFNI keeps giving me errors that the centers of the respective images are always 4-5 cm different in space, which simply can’t be. I wonder if there’s some positioning information being transmitted by our Philips scanner that is telling AFNI one of the scans is a different FOV or something…

Is there strong obliquity?

3dinfo -obliquity DSET1 DSET2 …

If so, consider running “3drefit -oblique_recenter” on the (maybe copied, to try it out) datasets.

  • rick