Open tsalo opened 1 month ago
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 https://github.com/nipreps/niworkflows/issues/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?
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 withfslr
(current files are in align withfsavg
).msmsulc
generates the subject'ssphere.reg
that is in align withfslr
, and we can use it to directly resample data toonavg
. 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 https://github.com/templateflow/templateflow/issues/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.
What would you like to see added in fMRIPrep?
I was reading Jeganathan et al. (preprint), and it seems like the
onavg
surface space would be preferable to fsaverage or fsLR in some (all?) situations, but the only surface spaces allowed for CIFTIs in fMRIPrep are fsLR-32k and fsLR-59k. I was wondering if it would be possible for fMRIPrep to add other CIFTI options.Perhaps
--cifti-output
could be merged into--output-spaces
, and the different CIFTI template combinations could be given unique identifiers there?EDIT: Or maybe the output space string could be expanded to allow both a surface template+density and a volumetric template+resolution?
Do you have any interest in helping implement the feature?
Yes
Additional information / screenshots
No response