"stingray" unfoldreg details

[jordandekraker]

I was just about to work on a branch for this, but started thinking about some big questions along the way that I would love to hear some weigh-in on:

• ANTs and Greedy both seem like fine methods, and I would lean slightly towards ANTs to stay consistent with previous work and keep the diffeomorphism small (since we expect the unfolding to do most of the heavy lifting already anyway). However, I wonder if we should also consider MSM (or newMSM) so we don't need to go from gifti to nifti and then back again.
• How to handle non-human data. The current behaviour is probably best to keep - wherin we expect vertex correspondence between subjects (of the same species) but not necessarily to human (thus we have species-specific subfield atalses). HOWEVER, for mouse-to-human mapping I actually want to have vertex-correspondence to the human (using a differmorphic unfoldreg of subfield labels). We could conisder applying this precomputed unfoldreg in all new mouse hippunfold runs (and an equivalent for marmoset, macaque, etc). Or, if we keep the current behaviour as-is, maybe we should make a module (or just instructions) for 1) computing this unfolded registration on custom data and 2) resampling nativesurfaces according to the unfoldreg. For both of these options, we'd need to think about how to name such unfoldreg surfaces, maybe we could add something like species-mouse|macaque|human or vertexcorr-mouse|macaque|human in addition to den, space, and label. This could easily be an addition after the v2.0.0 release though.

[akhanf]

For 2D registration, I also think ANTS is the better approach -- since it's 2D we don't really have to worry about computational efficiency (everything is fast in 2D). ANTS with CC metric might be better than MI too (once we sort out the curvature sign-flip issue can try that out).. Re: MSM, we could consider moving to a mesh-based approach like this, but I think given our topology is already rectilinear it is more sensible to just use image registration, and not sure how "hard-coded" the spherical topology is in MSM. We should still defnintely use richer features though like MSM does, e.g. myelin-maps, connectvitity etc -- that is a paper we should write shortly after v2.0..

Re: vertex correspondence in the nativesurf workflow, I think the issue comes down to us needing a universal template. Once we have one, we can register that universal template to all our surface templates (note: the registration between templates can be done in advance, eg as part of template generation, which I envision as just simply running hippunfold with a --generate-template option). That universal template could also be where the various density templates are first defined, but then mapped to every template, so when the user wants a particular density, the template they choose (whether human, macaque, mouse), will already have it, with corresponding vertices.

As for creating this universal template, I think it makes sense for it to be a groupwise average of multiple templates (multiple species included). We won't have subfield labels in this universal atlas, but will just generate surface meshes, and metric files (thickness, curv, etc.. ) for unfolded registration to the templates. Ie, the templates will be what a subject dataset will be registered to, and where subfield labels will come from.. Could call it hippaverage? We could also decide whether we just want to use this space by default (e.g. unfoldreg to template, then apply pre-computed warp to hippaverage)?

Now, for the sake of practicality, maybe what we should do is use the group-average of the multihist7 subjects as the hippaverage, and work at making a clean mesh in that space, before we try to tackle multi-species registration.. perhaps that version could be hippaverage2..

[jordandekraker]

Nice, I certainly lie the idea of a hippaverage one surface to rule them all*. Using the multihist7 makes perfect sense to me (at least, for now). I'll try my hand at generating such a template - previously I used antsMultivariateTemplateConstruction2.sh with the default CC metric. Applying this to the heavy_smooth_unfold_surf data could be quite nice.

If we're going to apply the same workflow to the DG (#334), I will have to apply some manual edits to the DG so that equivolume & laplace-beltrami will solve properly here. It would be good to merge #349 and use laynii first.

I believe I will also use only segmentations resampled to 100um - this doesn't seem to cut any folding detail and makes manual seg easier.

*Also note that for cross-species, this will result in oversampling of CA2 (which is smaller in non-human primates&rodents). I think this is fine though.