Write out fsnative surface files registered to fsLR space

[tsalo]

Is your feature request related to a problem? Please describe.

My understanding is that the resulting surface files will have the same vertices and mesh as the standard-space (dhcpAsym or fsLR) surface, but will retain the subject's fsnative geometry. This way users can visualize standard-space surface maps on the subject's unique topology (sulci, gyri, etc.), as is recommended in Jeganathan et al. (preprint).

Describe the solution you'd like

sMRIPrep would output pial, white matter, midthickness, inflated, and very-inflated surface files with space-fsLR.

Describe alternatives you've considered

Currently, XCP-D performs this step, but I'm pretty sure the nipreps team and DCAN lab have discussed it and wanted to move it into sMRIPrep/fMRIPrep/Nibabies.

Additional context

This is a duplicate of nipreps/nibabies#367.

[tsalo]

XCP-D's workflow includes the following steps:

1. Split up the anatomical-to-template transform (any volumetric template is fine) from fMRIPrep into affine and warpfield components.
2. Convert the affine transform into a world transform format.
3. Convert the warpfield transform into FNIRT format. The same is done for the warpfield component of the template-to-anatomical transform as well.
4. Convert the sphere.reg file to GIFTI format.
5. Project the sphere_reg file to fsLR to get a sphere_reg_fsLR file.
6. Resample the pial and white matter surfaces to fsLR-32k.
7. Apply the world-format affine to the pial and white matter surfaces.
8. Apply the FNIRT-format warpfield to the pial and white matter surfaces.
9. Generate new midthickness, inflated, and very-inflated surfaces from the fsLR-space pial and white matter files.

I don't think steps 1-3 or 7-8 are necessary for sMRIPrep. My understanding is that XCP-D only does this so the surfaces can be overlaid on top of the volumetric anatomical outputs that have been warped to the chosen template. XCP-D should be able to do the same thing after the rest of the steps.

sMRIPrep already does steps 4 and 5, and it seems to apply step 6 only to the midthickness files in init_resample_midthickness_wf. I think we just need to make init_resample_midthickness_wf more general to apply the same step to the pial, white matter, inflated, and very-inflated files.

[effigies]

I'm +1 on this. I can't see a really good reason not to apart from that we need to decide a naming convention. BEP011 is silent on this, so we should probably eventually propose it to BIDS.

I guess:

sub-X_hemi-<hemisphere>_space-<mesh>_den-<density>_<pial|midthickness|white|etc>.surf.gii

I think this would be consistent with using space-fsLR for sphere.reg.

[tsalo]

In XCP-D we name them something like this (i.e., we just use space-fsLR):

sub-<label>_hemi-<L|R>_space-fsLR_den-32k_pial.surf.gii
sub-<label>_hemi-<L|R>_space-fsLR_den-32k_white.surf.gii
sub-<label>_hemi-<L|R>_space-fsLR_den-32k_desc-hcp_inflated.surf.gii
sub-<label>_hemi-<L|R>_space-fsLR_den-32k_desc-hcp_midthickness.surf.gii
sub-<label>_hemi-<L|R>_space-fsLR_den-32k_desc-hcp_vinflated.surf.gii

I'm happy to defer to surface experts though.

[effigies]

So desc-hcp_inflated.surf.gii is actually the HCP inflated surface and not the subject's? So that should be identical across subjects... I think when BEP038 is in, dumping it into tpl-fsLR_hemi-<L|R>_inflated.surf.gii might make more sense.

[tsalo]

No it's the subject's, but created using the HCP pipeline's approach (vs... I think Freesurfer's approach?).

[effigies]

Got it.