Support HCP-compatible CIFTI outputs

[effigies]

For consideration after #1001 is merged.

CIFTI is in a somewhat weird state where pretty much every CIFTI file that exists was created by or for the HCP ecosystem, despite it being a generic format. Hence, almost every CIFTI is in the 91282 Greyordinate space, which is defined by the 32k_fs_LR surface space, and some unspecified variant of MNI152 for the subcortical volumetric space.

Right now we're targeting fsaverage5 for the surface space and MNI152NLin2009cAsym as the volumetric space subcortical voxels are aligned to. The primary advantage to the current approach is consistency with other FMRIPREP outputs, as well as standard FreeSurfer spaces.

If users are interested in directly comparing their data with HCP data, or using tools that assume HCP preprocessing, it may be useful to target the HCP grayordinate space.

[mgxd]

I'm starting this up now - some thoughts/questions/concerns/etc going forward..

• Do we want to add workbench as a dependency for this? This would be pretty useful for the surface conversion from fsnative to 32k among other things

additions:

• an option hcp-32k to output_spaces
• 32k_fs_LR download to niworkflows
• resample (ideally downsample) BOLD surfaces to 32k (2mm) resolution
• resample BOLD to the hcp variant of MNI152 and use this atlas for subcortical mapping (@edickie do you happen to know this variants name?)
• MSMSulc registration (maybe not in this PR, but thoughts on this?)

I may be overlooking some steps - feel free to suggest other additions

[edickie]

I don't think you can do it without wb_command as a dependency. It's pretty critical for most of the surface warping and resampling steps..plus putting the surfaces and subcortical data together into a cifti file. Is anyone working on nipype interfaces for it? I don' t think I saw any last time I looked. I guess the 91282_Greyordinates and 32k_fs_LR are pretty much the same "space": + (32k (left surface vertices) + 32k (right surface vertices) + 32k subcortical voxels = 91282_Greyordinates) MSMSulc (the newest version) registration is really computationally expensive (it adds 2.5 hrs to the workflow on a 16 CPU machine). But those at the HCP are insist that it is worth it (and that I make it the default behaviour in ciftify). Also, the newest version of the MSM binaries are only available fro academic use. So I think it is up to you.

…

On Wed, May 23, 2018 at 1:51 PM, Mathias Goncalves ***@***.*** > wrote: I'm starting this up now - some thoughts/questions/concerns/etc going forward.. - Do we want to add workbench as a dependency for this? This would be pretty useful for the surface conversion from fsnative to 32k <https://webcache.googleusercontent.com/search?q=cache:wnOVLyExrosJ:https://wiki.humanconnectome.org/download/attachments/63078513/Resampling-FreeSurfer-HCP.pdf%3Fversion%3D1%26modificationDate%3D1472225460934%26api%3Dv2+&cd=2&hl=en&ct=clnk&gl=us> among other things additions: - an option hcp-32k to output_spaces - 32k_fs_LR download to niworkflows - resample (ideally downsample) BOLD surfaces to 32k (2mm) resolution - resample BOLD to the hcp variant of MNI152 and use this atlas <https://github.com/edickie/ciftify/blob/master/ciftify/data/91282_Greyordinates/Atlas_ROIs.2.nii.gz> for subcortical mapping ***@***.*** <https://github.com/edickie> do you happen to know this variants name?) - MSMSulc registration (maybe not in this PR, but thoughts on this?) I may be overlooking some steps - feel free to suggest other additions — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1025 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMl59rBsTKsOI68Sig5r55adIZ02taiYks5t1aGygaJpZM4Sdmn4> .

[effigies]

Adding the connectome workbench to the dependencies is fine with me.

[oesteban]

Hi @mgxd, where are things as regards this issue?

[mgxd]

Hi @oesteban - currently I have a few more pressing things, but will come back to this when I can.

fyi @edickie - we added some initial support for workbench interfaces to nipype

[jcrdubois]

Hi all, I just recently started trying out fmriprep, after using predominantly HCP pipelines for a while. Has there been any progress on this issue? It would indeed be useful to output data that is in the same space as the HCP minimal preprocessing pipelines output. I can look into it with some guidance, if nobody else has time/interest to work through the issue.

[edickie]

Hi Julien, Currently, the simplest way to run this extra pipeline step after running fmriprep. https://edickie.github.io/ciftify We will start up a more integrated solution in the new year! Let me know if that makes sense. Erin

…

On Sat, Jan 5, 2019 at 12:14 PM Julien Dubois ***@***.***> wrote: Hi all, I just recently started trying out fmriprep, after using predominantly HCP pipelines for a while. Has there been any progress on this issue? It would indeed be useful to output data that is in the same space as the HCP minimal preprocessing pipelines output. I can look into it with some guidance, if nobody else has time/interest to work through the issue. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1025 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMl59pJX_cMT7lZBylnz94JmRlKRPlxsks5vAN1_gaJpZM4Sdmn4> .

[oesteban]

Closing in favor of the smaller issues referenced above. I hope they cover what @effigies, @mgxd and @edickie discussed in the beginning. Please add anything I might have missed on those issues.

The idea would be to:

1. Avoid MSM for now. Let's get HCP-compatible ciftis and then ask the community whether we should integrate MSM for a more accurate output.
2. Use the average fsLR (which also dismisses the LR information, that would be somewhat following alternative C on the document @mgxd referenced above - https://wiki.humanconnectome.org/download/attachments/63078513/Resampling-FreeSurfer-HCP.pdf?version=1&modificationDate=1472225460934&api=v2)