Trouble registering surfaces to fsLR space

[Johannes Achtzehn]

Hello,

I am just starting with surface based analysis of BOLD data. I am trying to resample and register the midthickness.surf.gii files (generated by fmriprep) into fsLR space.

Now I am using the command below in order to resample the output (aligned to individual T1w images) into fsLR 32k space. The mesh resolution changes accordingly (32492 vertices), but the mithickness surface is still registered to the individual T1w image instead of the fsLR template. I check this by loading the templateflow fsLR_den-32k_hemi-L_midthickness surface file (see screenshots below).

To me it seems like I a missing a step, e.g. when I move from template to T1w space for volumetric data, I have to apply a transform to the data. Is this necessary for surface data as well?

This is the command I am using:

wb_command -surface-resample /path_to_fmriprep_anat_folder/_hemi-L_midthickness.surf.gii # in_file /path_to_fmriprep_anat_folder/_hemi-L_sphere.surf.gii # current sphere /templateflow/tpl-fsLR/tpl-fsLR_den-32k_hemi-L_sphere.surf.gii # target sphere BARYCENTRIC /path_to_fmriprep_anat_folder/output.surf.gii # out_file

Right: individual midthickness surface, left: templateflow fsLR template

green: individual midthickness surface, blue: templateflow fsLR template

I have already asked in the neurostars forum but have not gotten a good answer. Thank you!

[Tim Coalson]

-surface-resample will never change the coordinate system or alignment of a surface, that isn't its job.  Surface registration doesn't modify the anatomical coordinates of any gyrus or sulcus, that isn't its job, therefore surface-based resampling won't, either.  Surface registration is a means of identifying corresponding points between two different surface meshes, and doesn't even need to know the anatomical coordinates.  fs_LR is not defined by an anatomical coordinate system, in fact group-averaged human fs_LR surfaces should not be expected to have good anatomical accuracy (for a similar reason that group-averaged human MNI volumes should not be expected to have good cortical detail).  If you want an MNI-aligned surface to come out of -surface-resample, you have to give it an MNI-aligned surface as the input, all it does is create a surface with the new mesh, with coordinates that follow the input surface's contours.  You can apply a volume transform to the vertex coordinates of a surface (see wb_command -surface-apply-affine and -surface-apply-warpfield), but that is entirely different than what surface-based resampling means.

The HCP individual T1w space is a rigid transform of the subject's scans (with distortion correction).  It is not expected to align with the individual's MNINonLinear space, which has been deformed to match the subcortical data to a group template.  We generate both fs_LR and native mesh surfaces in both of these volume spaces, the choice of surface mesh and volume space are orthogonal, and we use whichever combination is best suited for the question we want to answer.  The same fs_LR .func.gii file will display just fine on either the T1w fs_LR surface, or the MNINonLinear fs_LR surface (with the proper number of vertices, of course).

fMRIPrep is not an HCP-affiliated tool, I don't know exactly what design choices they made.  It is effectively a competitor to the HCP preprocessing pipelines, the method we developed and use.

Tim

--
You received this message because you are subscribed to the Google Groups "HCP-Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hcp-users+...@humanconnectome.org.
To view this discussion on the web visit https://groups.google.com/a/humanconnectome.org/d/msgid/hcp-users/78577374-0f4e-4390-8950-8811f15df8a4n%40humanconnectome.org.

[Johannes Achtzehn]

Hello Tim,

thank you for your detailed explanation, that clears up a lot of things. I was confused, as other solutions found on the web always suggested to just use -surface-resample, even in tutorials (e.g. see this tutorial), but my experience with volumetric data was telling me that this can't be enough to register two surfaces. 

Best, Johannes

[Tim Coalson]

That tutorial isn't trying to reconcile two coordinate systems (volume spaces), it is only trying to display fs_LR data on an individual surface.  Since that doesn't involve a volume file, it doesn't need to care about MNI versus rigid space.  Surface-based methods separate the 3D alignment problem (which for adult human cortex, is close to intractable for most regions, other than central sulcus and insula) from the correspondence problem (V1 is here in this subject, and there in that subject, so let's use the same fs_LR vertex indices to represent it in all subjects, regardless of what the individual coordinates are).  So, the tutorial there isn't wrong, it just doesn't mention that there is a complete disconnect between surface registration and 3D alignment.

You could register surfaces without even trying to align volumes across subjects, but in practice, to study noncortical structures, volume alignment is still required.

Tim