bugfix for warps hemi-L

[jordandekraker]

I noticed there were still some issues with the warps from-unfold_to-native. I think this can be solved and the code simplified by simply running create_warps AFTER unflipping.

For the record, i think there is a difference between concatenating desc-flipLR_type-itk_xfm.txt onto existing transforms and flipping with c3d -flip x. I think one of these applies to the header only, while the other applied to the actual image. These should be equivalent, but i don't think that ANTs reads them the same way. Either way, this circumvents the issue entirely.

I tested once for a standard T1w modality and once for a cropseg modality (where output space is corobl) and both seem to work.

[akhanf]

But does this then mean you would have manually flip before applying the warp?
I'm occupied with a grant deadline right now but should be able to look at it later this week..

[jordandekraker]

nope, no manual flip required. the warp is now created with the coords already flipped back to their original orientation. thus, we don't need to flip again manually and we don't need to (as we previously did) have a step that concatenated a flipping transform

[jordandekraker]

Some rules in gifti.smk were still causing warps with hemi-Lflip to be generated, and surfaces then had to be flipped from Lflip to L. This can be skipped now. Tested and working with T1w data.

Overall this PR cleans up the code a fair bit too, removing a few rules.

[akhanf]

ok just about to try running the new updates -- but wanted to first just see what bug you are referring to. I transformed data from native to unfold and back again, both with left and right, and didn't come across any issues (aside from funny things at the boundary likely related to inverse inconsistency) -- what issues were you having?

antsApplyTransforms -t hippunfold/sub-000/warps/sub-000_hemi-R_label-hipp_from-T2w_to-unfold_mode-image_xfm.nii.gz -i hippunfold/sub-000/anat/sub-000_hemi-R_space-T2w_desc-subfields_dseg.nii.gz -o test_hemi-R_native_to_unfold.nii.gz -r hippunfold/sub-000/warps/sub-000_space-unfold_label-hipp_refvol.nii.gz  -v -n NearestNeighbor

antsApplyTransforms -t hippunfold/sub-000/warps/sub-000_hemi-R_label-hipp_from-unfold_to-T2w_mode-image_xfm.nii.gz -i test_hemi-R_native_to_unfold.nii.gz  -o test_hemi-R_native_to_unfold_to_native.nii.gz  -r hippunfold/sub-000/anat/sub-000_hemi-R_space-T2w_desc-subfields_dseg.nii.gz  -v -n NearestNeighbor

antsApplyTransforms -t hippunfold/sub-000/warps/sub-000_hemi-L_label-hipp_from-T2w_to-unfold_mode-image_xfm.nii.gz -i hippunfold/sub-000/anat/sub-000_hemi-L_space-T2w_desc-subfields_dseg.nii.gz -o test_hemi-L_native_to_unfold.nii.gz -r hippunfold/sub-000/warps/sub-000_space-unfold_label-hipp_refvol.nii.gz  -v -n NearestNeighbor

antsApplyTransforms -t hippunfold/sub-000/warps/sub-000_hemi-L_label-hipp_from-unfold_to-T2w_mode-image_xfm.nii.gz -i test_hemi-L_native_to_unfold.nii.gz  -o test_hemi-L_native_to_unfold_to_native.nii.gz  -r hippunfold/sub-000/anat/sub-000_hemi-L_space-T2w_desc-subfields_dseg.nii.gz  -v -n NearestNeighbor

native hemi-L subfields:

native -> unfold -> native hemi-L subfields

[akhanf]

doesn't this change the behaviour to now use laplace instead of shape-injection initialized fields for the dentate?

[jordandekraker]

Currently, they're the same thing actually (see rule linked below)
However, if we do end up refining the Laplace fields in the dentate in the future, then this is the filename we will want to use.

hippunfold/hippunfold/workflow/rules/autotop.smk

Line 86 in 80d35b7

rule laplace_coords_dentate:

[akhanf]

ah ok, I'm guessing we added that cp rule to avoid changing later rules.. I would prefer actually removing that cp rule to avoid confusion, but can perhaps can clean that up in another PR..

[jordandekraker]

we actually still use it to populate the coords folder in the output directory as well

[jordandekraker]

I'm actually wondering if my issue was specific to v1.0.0. I don't see any changes that seem relevant since then, but maybe I missed some.

The issue is that in hemi-L, if you unfold and then refold (or unfold the right hemisphere and refold it to the left hemisphere space), the image is the right orientation and so it loads as a subfield overlay in ITKSNAP, but the header affine still places it on the opposite side of the brain.

I came across the issue while trying to set up 2D registrations in unfolded space, and it will become a bigger issue if we want to concatenate unfold-2dregister-refold transforms all together.

[akhanf]

yes, the workflow was considering unfolded L and Lflip to be distinct, so I guess the main change here is just to use the same unfolded space for L and R (ie not have a Lflip space).

That certainly does simplify things, I would just want to make sure we aren't breaking anything along the way. I can't recall why we had the distinction between Lflip and L in the unfolded space in the first place.. Only thing I can think of is if we wanted to allow for different physical unfolded coordinates for left and right (e.g. side-by-side) - they are identical right now, which is why I think it just works to remove the L and Lflip distinction, but it would mean we couldn't do that in the future I guess?

[jordandekraker]

By all means, I was hoping you'd help me make sure we're not breaking something with this change.

By my understanding, the actual unfolded space is always the same even before we eliminate hemi-Lflip. The thing that mainly changes is that create_warps.py now finds an interpolation from unfolded to xyz in hemi-L instead of unfolded to xyz in hemi-Lflip.

As far as I know, nnunet.smk, shape_inject.smk, and the Laplace initialization for autotop.smk (that comes from shape_inject.smk) must be done in hemi-Lflip. Laplace coords then need to be flipped back to hemi-L to populate the output coords folder, and once that is done I don't think there are any other steps that need to be in hemi-Lflip

[akhanf]

Yep I don't see a major downside to eliminating Lflip in unfolded space, since we aren't setting L and R to be different there, and it does simplify things alot!

I'll run it through end-to-end and make sure the surfs and vols get warped properly.

[akhanf]

tested end to end transforming vols and surfs and all looks good!
nice catch to eliminate extra complexity! I'll merge this in