surface-based registration – if inputting volumes what should they be registered to?

[Chris Allen]

Dear Cosmo people,

Thank you for the great toolbox! I have a (probably naive) question about the surface-based classification and registration:

When I run, say, the surface-based searchlight, inputting functional volumetric data (from FSL), it seems to work fine if I give it volumes registered to standard (MNI) space, with classification in the places you’d expect, even though the surfaces from freesurfer are aligned to/based on participants T1 structural. Whereas if I pass it functional data registered to the T1 used by freesurfer the alignment is off and large areas of the surface have no functional data associated. Naively I would have thought functional data should be registered to the same space as the surfaces and the move to standard space can be avoided (in theory good for single participant-level analyses). Or is there an internal transform applied that I’ve missed – like is the transformation matrix inside nbrhood.origin.a.vol.mat applied? Basically, should I be using volumetric functional data registered to standard (MNI) space? Sorry if my question misses something obvious, I’ve only just started using classification and surfaces.

Thanks,

Chris

[Nick Oosterhof]

Greetings,

> On 13 Jul 2023, at 12:52, Chris Allen <c.p.g...@gmail.com> wrote:
>
> Thank you for the great toolbox!

Nice to hear that.

> I have a (probably naive) question about the surface-based classification and registration:
>
> When I run, say, the surface-based searchlight, inputting functional volumetric data (from FSL), it seems to work fine if I give it volumes registered to standard (MNI) space, with classification in the places you’d expect, even though the surfaces from freesurfer are aligned to/based on participants T1 structural. Whereas if I pass it functional data registered to the T1 used by freesurfer the alignment is off and large areas of the surface have no functional data associated. Naively I would have thought functional data should be registered to the same space as the surfaces and the move to standard space can be avoided (in theory good for single participant-level analyses).

In my experience you don’t have to loose much by moving to standard space. Plus you have the advantage of being able to use brain atlases / coordinates when in standard space.

When using AFNI, one can apply motion correction, alignment between EPI and anatomical, and transformation to a standard space (3 transformations) in one step. This is achieved by combining the affine transformations into a single transformation (per volume). The advantage is that interpolation is only done once for each volume. Also, with typical head movement of at least half the size of a voxel, I would think that also interpolation effects will not got worse when moving to a standard space.

A quite old script (python 2) that may be helpful: https://github.com/PyMVPA/PyMVPA/blob/master/mvpa2/support/afni/lib_prep_afni_surf.py

> Or is there an internal transform applied that I’ve missed – like is the transformation matrix inside nbrhood.origin.a.vol.mat applied? Basically, should I be using volumetric functional data registered to standard (MNI) space? Sorry if my question misses something obvious, I’ve only just started using classification and surfaces.

It should also work fine with data in standard space. I wonder if the data format maybe has multiple transformations stored of which only one is used. I also remember AFNI having problems displaying the overlay correctly with oblique volumes.

[Chris Allen]

Thanks for the response. Very helpful.

So I take it: Cosmo does default to requiring volumetric data in standard (MNI) space.

If so is there a way to get it to work in participant T1 space? Yes, a few transforms are applied to our data (motion correction, functional to T1 space etc), but as some of our analyses work with individual differences in anatomy we risk losing this information through the move to standard space. Perhaps if you could point me to where the transform cosmo applies (from standard to freesurfer T1, I presume) is, I can work it out. Thanks again.

Best,

Chris

[Nick Oosterhof]

> On 14 Jul 2023, at 10:02, Chris Allen <c.p.g...@gmail.com> wrote:
>
> Thanks for the response. Very helpful.
> So I take it: Cosmo does default to requiring volumetric data in standard (MNI) space.

Actually I don’t think I said that. Assuming that transformation matrices are set correctly and in a way that CoSMo understands, I don’t see why it should not work in native space.

> If so is there a way to get it to work in participant T1 space? Yes, a few transforms are applied to our data (motion correction, functional to T1 space etc), but as some of our analyses work with individual differences in anatomy we risk losing this information through the move to standard space. Perhaps if you could point me to where the transform cosmo applies (from standard to freesurfer T1, I presume) is, I can work it out. Thanks again.

- CoSMo itself has support for going between voxel- and world-coordinates in cosmo_vol_coordinates.
- For surface-based searchlights where the source data is in volume space (which I presume you are running), the key logic is done in the surfing toolbox (https://github.com/nno/surfing). surfing_voxelselection is called from cosmo_surficial_neighborhood.

In all cases, these functions are supposed to use the voxel-to-world transformation matrix defined in .a.vol.mat. So if the transformation seems off, it is probably a good idea to check that the matrices are as expected.

[Chris Allen]

Great, thanks for the pointers. 

Best,

Chris