AFNI viewer: T1w-space anat and bold not aligned

Hi there. I’m running the following codes on fMRIprep ver. 23.2.0. There’s no output file sub-X_space-T1w_desc-preproc_T1w.nii.gz, but only sub-X_space-MNI152NLin2009cAsym_desc-preproc_T1w.nii.gz.

fmriprep-docker '/media/menglab/work2_4T/hy/face_imagery' 
'/media/menglab/work2_4T/hy/face_imagery/derivatives/fMRIprep' -w 
'/media/menglab/work2_4T/hy/fMRIprep_working_directory' --fs-license-file 
'/home/menglab/freesurfer/license.txt' --participant-label 2 3 4
 --ignore slicetiming --output-spaces anat MNI152NLin2009cAsym --skull-strip-t1w force 

I tried masking the sub-X_desc-preproc_T1w.nii.gz with the brain mask derived from fMRIprep, but the output file wasn’t aligned with any of the sub-X_task-X_run-XX_space-T1w_desc-preproc_bold.nii.gz files.

Hi @Yan_Huang,

There is not supposed to be sub-X_space-T1w_desc-preproc_T1w.nii.gz. The sub-X_desc-preproc_T1w.nii.gz (with no space label) is your T1 in subject space.

Hard to help this without seeing pictures or having any data to look at.


Hi @Steven,
Actually, what I’m trying to do is use the preprocessed T1w as the underlay, while other bold images as the overlay in AFNI. There’s no problem doing it with sub-X space-MNI152NLin2009cAsym_desc-preproc_T1w.nii.gz as the underlay, even if using sub-X_task-X_run-XX_space-T1w_desc-preproc_bold.nii.gz files which are coregistered to the T1w image. Both the underlay and overlay are displayed.

However, when using sub-X_desc-preproc_T1w.nii.gz as the underlay, I can’t display any image other than itself as the overlay. Otherwise, the software automatically replaces the underlay with another file (for example here, sub-X space-MNI152NLin2009cAsym_desc-preproc_T1w.nii.gz).

BTW, the underlay here has the ‘space’ label (I derived it from merging the sub-X_desc-preproc_T1w.nii.gz and the brain mask). The same result above also applies to the non-skull-stripped one (sub-X_desc-preproc_T1w.nii.gz)

Can you reproduce this with any other visualization software?

1 Like

Oh, I tried it on SPM just now. The underlay and overlay are displayed normally. Could it be a problem specific to AFNI?
I notice that the sub-X_space-T1w_desc-preproc_T1w.nii.gz is displayed in the ‘Original View’ but not in the ‘Talairach View’ like any other image.

I guess it could be but I do not use AFNI standalone, so I don’t know how AFNI viewer works.

1 Like

I found the solution. I changed the template space of the T1w image into TLRC (just the dataset’s header, not the file itself) with the AFNI command 3drefit -space TLRC dataset. Now it’s displayed normally just like in SPM.

The reason causing this problem is that the BOLD images in space-T1w derived from fMRIprep are in the TLRC space, while the T1w itself is in the ORIG space. This causes AFNI to switch between spaces when displaying these images, making them unable to overlap. Strangely though, it won’t be a problem between images in TLRC and MNI space.

BTW, I also found the T1w image is 2 degrees oblique while other images are 0, and had to deoblique it with 3dWarp -deoblique to align to the rest of the images.

I’m thinking maybe it’ll be kind of the fMRIprep developers to consider adding this changing feature to the T1w image in the processing pipeline. Because other AFNI users may come upon the same problem, too.

Thanks for your heads-up about checking it across different software. It helps me solve this problem that has been with me for a week. :slight_smile:



Just to comment on some features of AFNI.

Background, about spaces

  • In the NIFTI header, there are the sform_code and qform_code values, which are integers that essentially encode whether the dataset is in an “original” subject space or whethether it is in some “aligned” space, like a reference template. (Annoyingly, there is one code value, “2”, that is ambiguous, so it could be either—sigh. But let’s ignore that for the minute—only certain software populate that code value, and I don’t think it is being used here.) So, if you have a dataset with sform_code or qform_code 3, 4 or 5, that dataset is in a standard space, for example, namely Talairach-Tournous (TT), MNI or “other template”, respectively. You can use this to view the code values for one or more dsets:

     nifti_tool -disp_hdr -field sform_code -field qform_code -infiles DSET1 [DSET2 DSET3 ...]
  • In AFNI, this concept is encoded in the “space” and “AFNI view space (av_space)” of the header, whether the dset itself is BRIK/HEAD or NIFTI format. If the dataset is in some original space, space will be “ORIG” and av_space will be “+orig”. If the dataset is in some standard space, the av_space will generically be “+tlrc” (NB: for historic reasons it is called this, but it now just reflects any template, not just TT); the “space” value will generally be more informative about the specific space name, such as “TT_N27”, “MNI”, “MNI_2009c_asym”, “HaskinsPeds”, “NMT2”, etc. To view the value of this for one or more dsets, whether the dataset is NIFTI or BRIK/HEAD, use:

    3dinfo -space -av_space -prefix DSET1 [DSET2 DSET3 ...]

Some further notes on the sform_code and qform_code are here. Specific notes on NIFTI and BRIK/HEAD similarities and differences are here. Some notes on NIFTI (and specifically NIFTI+AFNI working together, since historically NIFTI has been primarily developed and maintained by AFNI developers) are [here](8.1. The NIFTI format — AFNI, SUMA and FATCAT: v24.0.02, though the ambiguous [qs]form_code values were included to maintain IMG/HDR format properties from other software.).

OK, now to the point of the GUI:

  • An original design feature in the GUI was to prevent people from overlaying/underlaying datasets that were in a template space with ones in original space. The idea was that data in different spaces wouldn’t be expected to be aligned anyways, and that this might help prevent confusion among a myriad of datasets.
  • Therefore, the AFNI GUI will not show an underlay-overlay pair together if one dset is in a standard space and the other is in a native space. That is, if:
    • 3dinfo would show a “+tlrc” av_space for one and “+orig” space for the other
    • NIFTI [sq]form_code value is 3, 4 or 5 for one dset and 0 or 1 for the other.
  • Note that you can overlay any two templates on each other–so, you can overlay/underlay something with sform_code=4 with a dset having sform_code=5, or av_space “MNI” with av_space “NMT2”, say.

It would be odd to see a NIFTI dataset in subject T1w-space have a sform_code and qform_code that basically says, “hey, i’m in template space”. Is there some reason that that should happen? Is it possible that the sform_code/qform_code value of that dataset is the dreaded ambiguous “2”? Looking at a couple AFNI Message Board posts, I think that might be the case: see here.

So, if that is the case, you can direct AFNI how to treat the ambiguous qform_code and sform_code values of 2, using an AFNI environment variable. You can set this in your ~/.afnirc file of environment variables:


After that, the ambiguously coded NIFTI datasets will be treated as having av_space “+orig” instead of “+tlrc”, which is how they must currently be treated. It would be nice to not have amiguous header information, though, if that were possible.

Re. obliquity: it is unfortunate to have obliquity in the anatomical dataset, often. Different software deal with it differently. Basically, the issue it causes is just a visualization one for any GUI:

  • if you apply the obliquity, you have to re-grid or interpolate the data, and that creates some blurring, and you can’t click on a location and see the actual value from the real dataset.
  • if you ignore the obliquity*, you click somewhere on the brain and see the correct, exact, uninterpolated values in the data, but the (x,y,z) coordinate location there is not what it was in the scanner, and if you try to overlay/underlay another dataset that has a different grid and/or obliquity, they won’t overlap properly.
    Different softwares make different choices for visualizing. Some apply the obliquity automatically (I think FSL does this?), and AFNI chooses to ignore the obliquity part. Either way, it’s a tradeoff, but you should know what is going to happen, certainly.

During processing, obliquity should just be dealt with by the tools properly, so again the visualization considerations are separate (though visualizing data is important!).

Having EPIs with obliquity is fine, because by the end of preprocessing they generally have been aligned to something else and you don’t have to worry about obliquity considerations anymore. For anatomical dsets to have obliquity can be a bit more painful, as you are seeing. We typically recommend that people remove the obliquity from those before preprocessing, to not cause issues/mismatched assumptions, esp. across software. Typically, anatomical obliquity is not too large—if it is, or if one is doing specialized slab/slice alignment, one might want to not do this, but except in those cases, you could consider getting rid of obliquity in a way that neither interpolates the data nor changes the coordinate origin (x,y,z)=(0,0,0) by doing this for your DSET_IN (and see this thread):

3dcopy DSET_IN _tmp_dset                            # copy to BRIK/HEAD
3drefit -oblique_recenter _tmp_dset+orig         # recenter, obl transform is now just mainly rotation
3drefit -deoblique _tmp_dset+orig                    # purge obl info

# ... and then if you want a NIFTI output
3dcopy _tmp_dset+orig DSET_OUT.nii

Another option would be to just apply the obliquity of the anatomical dataset, using 3dWarpDrive. We did that in processing the NARPS data, for example:

3dWarp                                                                       \
    -deoblique                                                               \
    -wsinc5                                                                  \
    -prefix     ${sdir_deob}/${subj}_T1w-deobl.nii.gz                        \
    -gridset    ${grid_template}                                             \

That incurs a slight blurring during the regridding, which using -wsinc5 minimizes. This is the approach that FreeSurfer’s recon-all would take if you input an oblique anatomical: apply the obliquity and process from there.

Sorry for the long post here, but there were several topics to cover. I hope some of that is useful.



The [sq]form_code of the EPIs in subject T1w space are indeed 2 (like you said), while the anatomical value is 1. I readopted your way of adding the environment variable and it worked fine.

N-1 header file '/media/menglab/work2_4T/hy/face_imagery/
sub-2_task-fh_run-01_space-T1w_desc-preproc_bold.nii.gz', num_fields = 2
  name                offset  nvals  values
  ------------------- ------  -----  ------
  sform_code           254      1    2
  qform_code           252      1    2

N-1 header file '/media/menglab/work2_4T/hy/face_imagery/
sub-2_space-T1w_desc-preproc_T1w.nii.gz', num_fields = 2
  name                offset  nvals  values
  ------------------- ------  -----  ------
  sform_code           254      1    1
  qform_code           252      1    1

Thanks again for your very informative help :smiley: