simplified outputs by concatenating label-hipp/dentate

[jordandekraker]

This is just an idea, and I'd like to hear feedback @akhanf @royhaast @myousif9 @Bradley-Karat

I was thinking it might be nice to concatenate label-hipp and dentate output files (they would still have no topological connectivity, but it may help simplify future work).

Basically, we'd keep work/ as is, but concatenate where appropriate when moving to hippunfold/. In cases where we don't have dentate data, we'd simply concatenate the appropriate number of NaNs (eg. for inner/outer.surf.gii, or for thickness.shape.gii).

Pros:

• make it easier to do things like sample separate images (fMRI, T1/T2w, DWI, etc) using a singe call to wb_command -volume-to-surface-mapping
• help simplify the plotting functions and examples i'm working on in https://github.com/jordandekraker/hippunfold_toolbox.
• reduce the clutter in hippunfold/sub-{subject}/surf a bit
• when loaded into a viewer, you don't need to specify as many files. Most programs will simply not render NaNs which i think is the desired behaviour here

Cons:

• restructures output files, so we'd need another (minor?) release
• doesn't drive home the fact that DG is anatomically topologically distinct as hard (though it would still be distinct)
• less control (eg. if you want to use only one of the two hipp or dentate, you'd have to remove or mask out the other)

Thoughts?

[akhanf]

I do see that there could be some value to having a surface file with the multiple hipp components combined (maybe also L+R?). However I am not sure combining their geometries in the same gifti is the best approach, since it limits what can be done with them as you suggest.

The enhancements to the CIFTI format that we discussed at a high-level with David and Matt to do in the near future could resolve the issues you bring up. E.g. right now, using CIFTI is the solution to putting L+R cortex surfaces together. The new additions to the CIFTI format (to add hipp and dg) would then allow cortex+hipp+dg (optionally even L+R) to be combined in the same CIFTI file, and then wb_command cifti_* operations would work on the combined surfaces (and would be a single file for easier viewing etc)..

Since that is on the horizon, I don't think it makes sense to diverge from that significantly (since the cifti solution would not involve concatenating geometry directly in giftis)..

That said, as a short-term workaround if you want to try it out, you could add some rules to concatenate the surfaces in the way you suggest, and also a target rule to generate them all. This would add the functionality, but would not be run by default. In general I think this is a good way to add anything more experimental.

[akhanf]

Note that the cifti solution doesn't help with the-volume-to-surface-mapping operation..

To make that operation fewer steps for the user you would need to either write a wrapper, or do your suggested concatenation.