follow_ROI_FS_REN_epi not aligned with anatSS

[zhengchencai]

Hello AFNI experts,

I processed fMRI data using afni_proc.py in the original space. The anatomical image was processed with @SSwarper2, followed by recon-all and @SUMA_Make_Spec_FS.

The Freesurfer segmentation file aparc.a2009s+aseg_REN_all.nii.gz appears to align well with anatSS.sub-ep069_anat.nii when viewed in Mango which I assume applies a deoblique transformation automatically.

However, it is not the case when I overlay copy_af_FS_EN_anat on anatSS.sub-ep069 in AFNI

It could also be a false memory, but I recall that copy_af_FS_REN_anat usually aligns well with anatSS when I visulized them in AFNI in another dataset. This is the first time I have seen such a misalignment. Obliquity differs: anatSS has 3.427°, aparc has 0.000°

> 3dinfo -prefix -space -av_space -obliquity -orient -d3 -n4 \
  anatSS.sub-ep069_anat.nii \
  aparc.a2009s+aseg_REN_all.nii.gz

anatSS.sub-ep069_anat.nii	ORIG	+orig	3.427	LPI	-0.999999	-1.000000	1.000000	176	256	256	1
aparc.a2009s+aseg_REN_all.nii.gz	ORIG	+orig	0.000	RSP	1.000000-1.000000	-1.000000	256	256	256	1

The follow_ROI_FS_REN_epi which was resampled on epi after volreg is also not aligned with anatSS when viewing in AFNI

Same when I overlay follow_ROI_FS_REN_epi on pb02_sub-ep069.r01.volreg

However, I do have the following in the process code which align copy_af_FS_REN_epi+orig to volreg epi

# warp follower dataset copy_af_FS_REN_epi+orig
3dAllineate -source copy_af_FS_REN_epi+orig                     \
            -master pb02.$subj.r01.volreg+orig                  \
            -final NN -1Dparam_apply '1D: 12@0'\'               \
            -prefix follow_ROI_FS_REN_epi

Then pb02_sub-ep069.r01.volreg is aligned with anatSS...

The epi to anat aligment looks fine in the QC

When I overlay follow_ROI_FS_REN_epi on stats.sub-ep069_REML+orig.BRIK.gz they are off, but there is no oblique

> 3dinfo -prefix -space -av_space -obliquity -orient -d3 -n4 \
  stats.sub-ep069_REML+orig.BRIK.gz \
  follow_ROI_FS_REN_epi+orig.BRIK.gz
              
stats.sub-ep069_REML	ORIG	+orig	0.000	LPI	-3.500000	-3.500000	3.500000	5073	73	37
             
follow_ROI_FS_REN_epi	ORIG	+orig	0.000	LPI	-3.500000	-3.500000	3.500000	5073	73	1

Could you please help to understand this behavior of AFNI? Is this just a visualization issue? If everthing is well aligned, is there a recommended way to configure AFNI to show them correctly aligned? If I read BRIK data, follow_ROI_FS_REN_epi+orig.BRIK.gz and stats.subxxx_REML+orig.BRIK.gz using AFNI R script read.AFNI(), are they aligned by voxel 3D index?

Thanks a lot.

[zhengchencai]

I noticed that when the raw T1 input to Freesurfer is oblique, the resulting copy_af_FS_REN_anat appears misaligned with anatSS in AFNI. However, when the raw T1 is not oblique, the alignment looks correct. Does this sound like a correct understanding?

To fix or avoid this misalignment, I’m considering two possible approaches and would appreciate your input on which is preferred:

1. Deoblique the raw T1 using 3dWarp -deoblique before feeding it into @SSwarper2 and recon-all.
2. Use the raw (possibly oblique) T1 for both @SSwarper2 and recon-all, and then run @SUMA_AlignToExperiment after @SUMA_Make_Spec_FS to align the Freesurfer outputs with the raw T1 space.

Thanks a lot.

[ptaylor]

Hi, Zhengchen-

There are a lot of datasets in different steps mentioned here, maybe should start from the beginning.

The TL;DR is that we typically recommend deobliquing the anatomical dsets prior to processing (i.e., prior to both AFNI's sswarper2 and FreeSurfer recon-all). That way, there is no confusion or differing treatment of obliquity. The way we would deoblique would be with this program, adjunct_deob_around_origin:

adjunct_deob_around_origin                       \
    -input   sub-001_T1w.nii.gz                  \
    -prefix  sub-001_T1w_DEOB.nii.gz

FreeSurfer recon-all will apply the obliquity during its processing. That is fine, though we note that it will resample/regrid the data when it does, blurring it slightly.

Most AFNI alignment programs ignore the obliquity (except for align_epi_anat.py, which is why it is perfect fine to leave the obliquity in the EPI dsets). Hence, the mismatch, at least visually, in some of what you showed above, as datasets are mixed-and-match through different obliquity treatments.

The 3dWarp command you put will also apply the obliquity to the anatomical, again, blurring it a bit as it puts it into the scanner-based coordinates. We recommend using adjunct_deob_around_origin instead: this will remove the obliquity from the header, but in a way that preserves the location of the coordinate origin, where (x,y,z)=(0,0,0). That means there is relatively less coordinate shift from removing the obliquity. But importantly, this operation does not regrid the data, so no blurring is incurred.

How does that sound?

--pt

[zhengchencai]

Thanks a lot Paul. This is exactly what I am looking for. I will try with adjunct_deob_around_origin.

Just to confirm, if 3dinfo -is_oblique [input T1 image to sswarper2] returns 0, am I safe to assume that aparc.a2009s+aseg_REN_all.nii.gz from SUMA folder is aligned with anatSS? I know they do not have the same dim and are not on the same grid. I only use aseg by resampling it to the epi after volreg using 3dAllineate such that I can extract the tissue type of each epi voxel.

In other words, if 3dinfo -is_oblique [input_T1] returns 0, does that mean the full pipeline from @SSwarper2, to recon-all, @SUMA_Make_Spec_FS, and afni_proc.py, will behave the same as if I had first run adjunct_deob_around_origin on an oblique T1?

Based on what you explained, the following 3dAllineate code will not handle obliquity. Therefore, if my input T1 to recon-all is oblique, the output follow_ROI_FS_REN_epi will not be properly registered to volreg+orig, am I right? I am asking this because I read TSNR.subxxx+orig.BRIK and follow_ROI_FS_REN_epi.BRIK using AFNI R script read.AFNI(), and extract TSNR values for different tissue types, if they are not registered due to obliquity, I will redo the process.

3dcopy /EP_EEGfMRI/derivatives/freesurfer/SUMA/aparc.a2009s+aseg_REN_all.nii.gz                                            \
    $output_dir/copy_af_FS_REN_epi

# warp follower dataset copy_af_FS_REN_epi+orig
3dAllineate -source copy_af_FS_REN_epi+orig                     \
            -master pb02.$subj.r01.volreg+orig                  \
            -final NN -1Dparam_apply '1D: 12@0'\'               \
            -prefix follow_ROI_FS_REN_epi

Thanks

[ptaylor]

Hi, Zhengchen-

Yes, seeing 3dinfo -is_oblique DSET output 0 means you are at a good point for putting DSET into both recon-all and sswarper2; the data output by each should be in the same space. (As you note, the grids will be different, but the the space will be the same.) If you process FMRI data with afni_proc.py, you can load the aparc.a2009s+aseg_REN_all.nii.gz and similar datasets with -anat_follower_ROI .. and they will be regridded and mapped appropriately to the final EPI space+grid automatically.

3dAllineate on its own will ignore obliquity. If you input a T1 with obliquity into recon-all, it will come out with the obliquity applied. So, at least for my part, if it isn't too much time or data crunching, I would reprocess to make sure that things are as easy and matching as possible from the start. It will also be easier on further studies, too, to have simpler steps from the beginning.

--pt

[zhengchencai]

Hi Paul, thanks again. I totally agree, I will reprocess these cases with obliquity, as it is indeed a tidy way.

Sorry for one last question, I would like to better understand this obliquity issue. My understanding is that obliquity is a coordinate system business, not related to voxel data 3D matrix. So even if copy_af_FS_REN_epi+orig, copied from Freesurfer’s aparc.a2009s+aseg_REN_all.nii.gz, was generated using an oblique T1 as input, the data matrix of follow_ROI_FS_REN_epi (produced by 3dAllineate) should still be properly registered to the data matrix of the EPI, which is registered to anatSS (produced by @SSwarper using the same oblique T1) in afni_proc.py. Is this incorrect? Is the misalignment in the AFNI GUI just due to the viewer not accounting for the obliquity information in the header by default?

Thanks

[ptaylor]

Hi, Zhengchen-

Indeed, obliquity is an extra transform---essentially always a shift plus rotation---applied to the data, separate from the voxel data 3D matrix. The main hassle is the rotation part: if you apply it, then you regrid the data, by definition blurring it. If you ignore it, then your data look conveniently oriented within the FOV, but they are in a different coordinate system than the scanner coords.

The input anatomical to FreeSurfer's recon-all and to sswarper2 had obliquity.

FS applies the obliquity, regridding+blurring the data, so the output volumes, including the *REN* data, have the obliquity applied and are in scanner coords.

sswarper2 basically ignores the obliquity (but doesn't regrid/blur), so the output volumes are conveniently oriented within the FOV, but not in scanner coords. Hence, the divergence in overlay/underlay.

Removing obliquity in the anatomical prior to processing removes this source of divergence. Note that removing obliquity can be done in many ways. Doing it specifically with adjunct_deob_around_origin as noted above does not blur/regrid the data, and it preserves the coordinate origin of acquired scanner coords; there will be a bit of missing angular rotation in the data, relative to original scanner coords, but because the coordinate origin is preserved, this usually is not a big deal.

--pt