That's an interesting question. We used to allow fsaverage5+MNI152NLin2009cAsym, but people did not love that the results were incompatible with HCP-pipelines CIFTI files.

Now we are using space-fsLR to clearly label these, so we could go back to permitting other spaces, but we would need to be clear on the processes here. Do we run msmsulc with onavg as a target, and what data files would be needed to achieve that? What's an appropriate volumetric space?

cc @feilong

@jaysonjeg Might be a good person to tag as well...

I'm thinking about generating sphere surfaces for onavg that are in align with fslr (current files are in align with fsavg). msmsulc generates the subject's sphere.reg that is in align with fslr, and we can use it to directly resample data to onavg. I need to perform some archeology to find these files.

Regarding the space, my personal preference is onavg + MNI152NLin2009cAsym. I agree with @tsalo's idea to allow combinations. For a few commonly used combinations we can support their short names for convenience.

I'm interested in switching to SUGAR which seems to have superior performance than msmsulc. At this moment, using msmsulc to align to fslr and resample using files in align with fslr is probably the best choice.

Perhaps one way of specifying combined spaces would to just use :: to delimit the surface space definition from the volumetric space definition? For example, dhcpAsym:cohort-42:den-32k::dhcpVol:cohort-42:res-2 would produce CIFTIs with the surface parts aligned to tpl-dhcpAsym_cohort-42_hemi-L_den-32k_sphere.surf.gii and the volumetric parts aligned to tpl-dhcpVol_cohort-42_res-2_T1w.nii.gz (which might be a good CIFTI space for Nibabies).

EDIT: I've opened nipreps/niworkflows#881 about parsing surface-volume space combinations.

I'm thinking about generating sphere surfaces for onavg that are in align with fslr (current files are in align with fsavg). msmsulc generates the subject's sphere.reg that is in align with fslr, and we can use it to directly resample data to onavg. I need to perform some archeology to find these files.

@feilong does that mean any surface template could be used as long as its templateflow entry includes a sphere surface in alignment with fsLR?

I assume those files would be named something like tpl-<label>_space-fsLR_hemi-<L|R>_den-<label>_sphere.surf.gii on templateflow?

Yes, theoretically we can use any surface template, and the naming convention makes sense to me.

I have some reservations simply naming the reference space fsLR. In practice, there are a few similar registration targets associated with fsLR. Initially there was conte69. The HCP data was aligned using hcp196, and the latest HCPPipelines include hcp449. I tend to treat them as different references, as the folding patterns associated with each of them are slightly different.

The registration references are available at HCPpipelines/global/templates/standard_mesh_atlases/{L,R}.refsulc.164k_fs_LR.shape.gii.

In the GIFTI head, the related files are named with Q1-Q6_Related449, and the IDs of the 449 participants can be found in the command.

In earlier commits of the repository (9f6189aabf7699c62d79987937d241717882a555), the files were different, and the tags in the GIFTI head were Q1-2-3_Related196.

I have some reservations simply naming the reference space fsLR.

That makes sense, though I think it's a separate issue for templateflow as long as the preps use the label consistently.

I'm trying to figure out the next steps. How does this sound?

1. Incorporate a naming convention for CIFTIs into niworkflows' Reference class (see Distinguish between surface and volume spaces in Reference niworkflows#881).
   • We need to ensure that the surface and the volume parts can be distinguished in the Reference object.
2. Limit surfaces in sMRIPrep/fMRIPrep to those that have a sphere file in alignment with fsLR.
   • I assume MSMsulc only works with a specific "version" of fsLR?
3. Add the requested surface space and the requested volume space to the list of output spaces within fMRIPrep.
4. Generalize the CIFTI-related workflows in fMRIPrep and sMRIPrep to use any surface and volume spaces with the necessary files, with fsLR as an intermediate step in the workflow.
   • I think Nibabies uses the dhcpAsym surface as an intermediate step between fsnative and fsLR, so maybe it already has some useful code for this? @mgxd is that correct?
5. Modify output filenames to include volspace and maybe volcohort.

The steps make sense to me.

Theoretically MSMSulc can be used with any space, but in practice it's often used with fsLR. For our purposes, it's also reasonable to use it with fsLR. Regarding the "flavor" of fsLR, I'm inclined to use hcp449, which is most up-to-date.

I'm thinking about generating sphere surfaces for onavg that are in align with fslr (current files are in align with fsavg). msmsulc generates the subject's sphere.reg that is in align with fslr, and we can use it to directly resample data to onavg. I need to perform some archeology to find these files.

Regarding the space, my personal preference is onavg + MNI152NLin2009cAsym. I agree with @tsalo's idea to allow combinations. For a few commonly used combinations we can support their short names for convenience.

Hi, @feilong,

First, align onavg to the fsLR, then align the individual space to fsLR, and finally resample the individual space data to onavg. The onavg results obtained this way will still be influenced by fsLR.

Additionally, this approach requires either a single resampling or double resampling, with two resamplings potentially affecting the FWHM.

If you directly align the individual space to onavg and then resample the individual space data to onavg, the resulting onavg will only be influenced by the onavg template.

Hi @NingAnMe,

This is related to the templateflow issue we've been talking about templateflow/templateflow#171

The onavg template affords a resampling target, not a registration target. In our paper we used FreeSurfer's registration algorithm and registration target, and we've been discussing replacing them with MSMSulc and one of the fsLR registration targets (e.g, hcp449). This does not introduce an extra step.

We only resample the data once, from the individual's native space to onavg. To do so, we need the individual's sphere and onavg's sphere to be aligned to the same registration target. It does not matter which registration target it is.

The group statistics of the 1031 OpenNeuro participants can potentially be used as a registration target. We haven't extensively explored this possibility yet.