Resample surfaces to any space/density using Connectome Workbench. #473
Conversation
|
I believe the failed docs check was because TemplateFlow S3 hasn't been updated. |
|
@feilong I think we can do this just by updating the parameterization of the existing workflow. I pushed my suggestion directly, but feel free to force-push back to yours. Here are the diffs:
@mgxd This needs your review, since you use this function in nibabies. |
| sphere_reg_fsLR | ||
| GIFTI surface mesh corresponding to the subject's fsLR registration sphere | ||
| GIFTI surface mesh corresponding to the subject's fsLR registration sphere. | ||
|
|
||
| Outputs | ||
| ------- | ||
| ``<surface>`` |
There was a problem hiding this comment.
| ``<surface>`` | |
| ``<surface>_<space>`` |
|
|
||
| fslr_density = '32k' if grayord_density == '91k' else '59k' | ||
| workflow = Workflow(name=name) | ||
|
|
||
| inputnode = pe.Node( | ||
| niu.IdentityInterface(fields=[*surfaces, 'sphere_reg_fsLR']), |
There was a problem hiding this comment.
if the goal is to make this generalizable, this should be sphere_reg_{space}
There was a problem hiding this comment.
I believe that what @feilong has is registrations from fsLR to onavg.
There was a problem hiding this comment.
Yes, by default the sphere.reg generated by MSM is always registered to fsLR.
| sphere_reg_fsLR | ||
| GIFTI surface mesh corresponding to the subject's fsLR registration sphere | ||
| GIFTI surface mesh corresponding to the subject's fsLR registration sphere. |
There was a problem hiding this comment.
| GIFTI surface mesh corresponding to the subject's fsLR registration sphere. | |
| GIFTI surface mesh corresponding to the subject's ``space`` registration sphere. |
| resampler.inputs.new_sphere = [ | ||
| str( | ||
| tf.get( | ||
| template='fsLR', | ||
| density=fslr_density, | ||
| template=space, | ||
| density=density, | ||
| suffix='sphere', | ||
| hemi=hemi, | ||
| space=None, | ||
| space=(None if space == 'fsLR' else 'fsLR'), | ||
| extension='.surf.gii', | ||
| ) | ||
| ) |
There was a problem hiding this comment.
altering space in this templateflow query feels brittle - for instance, it will not be able to handle:
thinking we can either extract this out, or add a parameter tf_space to handle this - don't particularly love either tbh
There was a problem hiding this comment.
The usage of space- here resembles tpl-dhcpAsym_cohort-42_space-fsaverage_hemi-L_den-41k_desc-reg_sphere.surf.gii.
It is supposed to get the sphere file that bridges two spaces (e.g., dhcpAsym and fsaverage, onavg and fsLR).
I'm not familiar with dhcpAsym templates. Do the templates also imply space-fsLR when space is not specified?
I prefer to use atlas to refer to the registration target, because the registration target is mainly about the cortical folding patterns, but atlas is also an overloaded term...
|
@effigies Your suggestions make a lot of sense to me. The only reason I kept |
Adding
init_resample_surfaces_wb_wf, which is similar toinit_resample_surfaces_wfbut not limited to fsLR spaces.It can resample surfaces to the specified space and density if the corresponding files exist in TemplateFlow.
For non-fsLR templates, it needs the
space-fsLRfiles of the template, which connects the registered sphere (fsLR space) with the template (template space).For example, with
tpl-onavg_space-fsLR_hemi-L_den-10k_sphere.surf.giiit can resample the subject's surfaces tospace-onavg_hemi-L_den-10k.The code is mostly copied and modified from
init_resample_surfaces_wf.