Freesurfer aseg from @SUMA_Make_Spec_FS in native space

AFNI Message Board
1

I would like to use Freesurfer aseg atlas (aparc.a2009_aseg.nii) in the subject space. I think I’m so close and I found other posts related to this, but I can’t still figure out how to get the atlas in the native space.

I ran @SUMA_Make_Spec_FS (command I ran: @SUMA_Make_Spec_Fs -NIFTI -sid sub-01), and it created the SUMA directory, which has subj_SurfVol.nii and aparc.a2009s+aseg.nii (all beautiful!).

I found that sub-01_SurfVol.nii has 256, 256, 256 voxels (x,y,z) but my subject’s native T1 (say sub-01_T1w+orig) has 176, 256, 256 voxels, so I ran @SUMA_AligntoExperiment with sub-01_T1w+orig as exp_anat input. It created sub-01_SurfVol_Alnd_Exp+orig, but this one and aparc.a2009s+aseg.nii is still in 256/256/256 voxel space.

When I ran 3dresample to align aparc.a2009s+aseg.nii to align it to my native space, it didn’t align well. I think I could try 3dallineate, but I feel like I might be just missing something or not doing the first step in a correct way because, in other posts, I saw comments saying that the output from @SUMA_Make_Spec_Fs should be in the exact native space.

Could you give me any advice on this? Also, I’m generally confused 1) whether sub-01_SurfVol+orig is supposed to be in the native (T1) space (rectangle-like space) or in a freesurfer-ish space (square-like space where all dimensions have the same number of voxels), and 2) whether the output of @SUMA_AlignToExperiment is supposed to be in, in the native space.

Thank you!!

2

Howdy-

OK, indeed, FreeSurfer (FS) output will be a 256x256x256 matrix with 1x1x1 mm**3 voxels, regardless of input (you can actually specify using a higher res output if you have higher res input, but that doesn’t apply here). Your input to FS might not be the same matrix size or have the same voxel dimensions, indeed. Your input to FS might also have an obliquity matrix, which I don’t think the FS output will have—that obliquity matrix is an extra spatial transform (in practice, likely describing mostly a rotation+translation, though it could be more general), based on how you acquire your data.

Nomenclaturally, I would say that if there is no extra obliquity matrix in the input, then the FS output and the FS input are in the same space (they should overlay) but on different grids (voxel size and/or matrices differ).

To check about the obliquity of the input and outputs, what is the output of:


3dinfo -obliquity -prefix DSET

… for both your FS input and the SurfVol.nii?

You can also use 3dinfo to see if 2 or more dsets have the same grid (with the latter option sharing a bit more details about grid properties—please see the help description):


3dinfo -same_grid DSET1 DSET2 ...
3dinfo -same_all_grid DSET1 DSET2 ...

To have the same transformation between the two anatomical volumes also apply to the atlas (or atlases) of interest, you can input your atlas created by FS as a “follower”, such as here (use the “-atlas_followers” option, too, if the followers are all atlases, so that nearest neighbor interpolation is applied:


@SUMA_AlignToExperiment \
     -echo -exp_anat tmp_anat+orig. \
     -surf_anat FT_SurfVol.nii    \
      -atlas_followers \
       -prefix ATE \
       -atlas_followers \
      -surf_anat_followers aparc.a2009s+aseg_REN_all.nii.gz aparc.a2009s+aseg_REN_gmrois.nii.gz

It should then get translated and resampled (and interpolated) appropriately to your native/input anatomical space. The above gave me the following outputs:


ATE+orig.{BRIK,HEAD}
aparc.a2009s+aseg_REN_all.nii_Alnd_Exp+orig.{BRIK,HEAD}
aparc.a2009s+aseg_REN_gmrois.nii_Alnd_Exp+orig.{BRIK,HEAD}

…that all appeared to be on the input dset grid. Now, my input dset did not have obliquity, so I am not sure if it will match that—could you try and see if yours does (if you input dset did have obliquity, as seen above)? You can check the obliquity of these dsets, too with:


3dinfo -obliquity -prefix *Alnd_Exp*HEAD

Further, if you wanted to reattach the labeltables from the FS-created atlases to the @SUMA_AlignToExperiment ones, you could do this:


3drefit -copytables aparc.a2009s+aseg_REN_all.nii.gz aparc.a2009s+aseg_REN_all.nii_Alnd_Exp+orig.HEAD
3drefit -copytables aparc.a2009s+aseg_REN_gmrois.nii.gz aparc.a2009s+aseg_REN_gmrois.nii_Alnd_Exp+orig.HEAD

How does that all work?

–pt

3

Thank you so much!

Yes, the output of @SUMA_AlignToExperiment now has the same grid as the input T1, but the obliquity is different. My anatomical T1 input had obliquity. and the output doesn’t have any (just like the SurfVol file).

Do you recommend deobliquing the data (T1) from the beginning (before doing @suma_make_spec_fs)? I have other functionally defined ROIs from the obliqued data (yeah, I didn’t include deobliquing in my preprocessing step), so I would prefer to keep them in the same space, but if it is easier to keep everything in a space without the obliquity, maybe I can go with that.

Thanks a lot for your help! I love that I can just reattach the labels, too!

4

Oh, but visually, they look really well aligned even though the obliquity isn’t the same (attached the pictures)!
Do you think it is still not cool to use it as it is as they don’t have the same obliquity?

aligned_fs_axial.png

aligned_fs.png