fMRIPrep is a robust and easy-to-use pipeline for preprocessing of diverse fMRI data. The transparent workflow dispenses of manual intervention, thereby ensuring the reproducibility of the results.
I think surface and volumetric space both need to be indicated in filenames, as the current convention of using shorthand names for combinations of surface template and volume template (i.e., fsLR standing in for fsLR + MNI152NLin6Asym) doesn't extend well to arbitrary combinations.
In order to indicate both the surface and volume templates, I originally proposed adding cohort, volspace, and volcohort to filenames. However, most folks weren't a fan of that, so we've started going in the direction of using + signs in entities to incorporate multiple values (see bids-standard/bids-specification#1926). The thing is, in cases where one or both of the spaces in a CIFTI file (surface and/or volume) have an associated cohort value, the cohort entity doesn't really work. To use an example from https://github.com/nipreps/niworkflows/issues/881, if you wanted dhcpAsym:cohort-42 as the surface space and MNIInfant:cohort-1 as the volume space, the current approach would have an output like space-dhcpAsym+MNIInfant_cohort-42+1, which isn't very interpretable. Instead, appending the cohort directly to the template name might be clearer: space-dhcpAsym42+MNIInfant1.
Do you have any interest in helping implement the feature?
What would you like to see added in fMRIPrep?
I think surface and volumetric space both need to be indicated in filenames, as the current convention of using shorthand names for combinations of surface template and volume template (i.e., fsLR standing in for fsLR + MNI152NLin6Asym) doesn't extend well to arbitrary combinations.
In order to indicate both the surface and volume templates, I originally proposed adding
cohort
,volspace
, andvolcohort
to filenames. However, most folks weren't a fan of that, so we've started going in the direction of using+
signs in entities to incorporate multiple values (see bids-standard/bids-specification#1926). The thing is, in cases where one or both of the spaces in a CIFTI file (surface and/or volume) have an associated cohort value, the cohort entity doesn't really work. To use an example from https://github.com/nipreps/niworkflows/issues/881, if you wanted dhcpAsym:cohort-42 as the surface space and MNIInfant:cohort-1 as the volume space, the current approach would have an output likespace-dhcpAsym+MNIInfant_cohort-42+1
, which isn't very interpretable. Instead, appending the cohort directly to the template name might be clearer:space-dhcpAsym42+MNIInfant1
.Do you have any interest in helping implement the feature?
Yes
Additional information / screenshots
This is related to #3330, #3340, bids-standard/bids-specification#1926, https://github.com/nipreps/niworkflows/issues/881, and https://github.com/nipreps/niworkflows/issues/883.