I am looking for a subcortical atlas that can be used with the MNI152NLin2009cAsym template (default of fmriprep). I found a parcellation file from the fmriprep image named /niworkflows_data/mni_icbm152_nlin_asym_09c/1mm_parc.nii.gz, and I guess it was converted from the Harvard Oxford Atlas in FSL based on the scripts from the same folder.
I have two questions:
Is that parcellation file also in the MNI152NLin2009cAsym template space (instead of the MNI152 6th used by FSL)?
Is there any associated file that can map numbers in that file to label names?
We are working on this issue right now. Please check on the development of our templateflow project (https://github.com/templateflow/). We will be adding all the templates available to fmriprep there, including mappings of segmentations, parcellations and surfaces between them. I’ll be posting a preprint ASAP.
Regarding the two questions from @feilong (sorry for the huge delay in answering, this is probably useless to you at this point but will leave this here for people asking about it):
No, that parcellation corresponds to the MNI152 6th generation. We only regridded it to match MNI152NLin2009cAsym.
No, but as you mention that was done using the Harvard Oxford Atlas and the labels were mapped as in the scripts you already accessed.
With templateflow we will be addressing both two questions (which are extremely relevant, that must be said). Hopefully I can post updates here soon.
The problem is that Harvard atlases were produced with the MNI152 Linear version of the MNI templates. Although the MNI152Nlin2009cAsym is well aligned with the linear version, there will always be inconsistencies between atlases if they would have defined using the MNI152Nlin2009cAsym template as well.
In summary, by applying an atlas defined w.r.t. the Linear version of MNI152 on data aligned to MNI152Nlin2009cAsym you are dismissing some accuracy errors derived from the differences between templates.
Then you would think, why didn’t you use MNI152 linear as the registration target in the first place? The answer is that then you would be introducing similar accuracy errors but on your registration step. We considered that it was more important to have the best alignment possible to the standard space, assuming that the current lack of atlases defined on MNI152Nlin2009cAsym would be addressed at some point in time.
For these reasons, we are working on an easy way of transferring atlas information through different templates. That would be one of the objectives of the project I mentioned above (templateflow).
I’m having a similar issue where I’ve preprocessed my data in fmriprep using the MNI152NLin2009cAsym template, and an now performing an ROI analysis, using the Harvard-Oxford atlas from FSL (which is mapped to FSL’s MNI152 template).
With that being said, I have a few quick questions:
1). Can fmriprep (1.3.0 or higher) accept a different template, such as the MNI152NLin6Sym?
2). If not, is there a way to align the Harvard-Oxford atlas ROIs to the fmriprep output? When I’ve taken the output to FSL, I’ve followed this strategy for avoiding FSL’s registration step, since it’s already been performed in fmriprep. Thinking over my issue, my thought has been to allow FSL’s registration to the MNI152 template, but this seems like an unnecessary interpolation step.
As you will see in this conversation, that one looks very similar to FSL’s MNI152 but it is not quite the same thing.
We would like to include that template into TemplateFlow ASAP. We would be extremely happy to accept help in the task (that is the bottleneck at this point in time).
We’ve been taking steps towards making this possible, but it is not yet there. Creating TemplateFlow (a way to dynamically pull from a pool of templates that can be selected under a controlled vocabulary of identifiers) we solved a big portion of the problem. However, the latest releases (1.3.0 and higher) have mostly addressed issues derived from TemplateFlow’s integration. It seems that 1.3.2 is giving positive signals as to whether TemplateFlow’s integration has reached acceptable reliability and now we can move on and make use of TemplateFlow’s features.
In sum, the answer to this question is not yet.
If you could allow some time for us to provide with a good solution to this (i.e. generating the Harvard-Oxford segmentation on fMRIPrep’s MNI flavor) I could commit to having this included within TemplateFlow in one week.
If you can’t wait that long, then it depends on the inaccuracy in registration you’d be willing to accept. If you don’t need submm accuracy, then just resampling the HO atlas with an identity interface would work. Otherwise, you’ll need a solution where you run some registration protocol between MNI152NLin2009c and FSL152NLin2006Asym (which is what I’ll run to provide the first solution to this question).
Finally, the best solution is to wait for fMRIPrep to leverage TemplateFlow and allow you to set FSL152NLin2006Asym as target template. That will probably take the longest time.
Not yet. Adding the Harvard-Oxford atlas in MNI152NLin2009cAsym would be the final straw of ongoing work. For now, I’ll try to get it uploaded in its original MNI152NLin6Asym space ASAP. This way, at least you should be able to use it via the --template MNI152NLin6Asym flag.