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 https://github.com/nipreps/nibabies/issues/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.

[zhitao-guo]

@effigies Hi Chris, I hope you're doing well, and I'm sorry to bother you.

I’m encountering a puzzling issue with the output of fMRIPrep. I used fMRIPrep 24.1.1 and 24.0.1 on my system, but I can't generate the native fsLR 32k mesh files, even though other people have succeeded. Could you kindly help me interpret what might be causing this problem? Here is a link with more detailed information: https://github.com/PennLINC/xcp_d/issues/1305.

Thank you so much for your time and assistance!

[effigies]

This is an open issue and still needs to be implemented. I'm not sure what others are doing to retrieve these files. They exist in the working directory, but fMRIPrep does not emit them.

[zhitao-guo]

Thank you.

Just to confirm, the latest version of fMRIPrep (24.1.1) does output native fsLR 32k mesh files (sub-<subject_label>_hemi-[LR]_space-fsLR_den-32k*.surf.nii) in anat folder, right? I want to double-check that my docker image is running correctly, although the SHA256 hash of my image matches the one on Docker Hub.

I only found the resampled midthickness mesh files in the working directory. Could you please help me locate the path of other files? Thanks again.

[effigies]

No.

[effigies]

Apologies for the brevity, was in a meeting. This still needs to be done. I think you're right that only the midthickness is resampled, since only that is used as an intermediate derivative.

[zhitao-guo]

It doesn't matter. I'll try to generate other files I need using other methods, such as scripts from the HCP Pipelines. Looking forward to the release of the new version.