Registration V2

[edyoshikun]

This PR adds the following:

• CLI for manual estimation of affine transform
• CLI for optimizing an affine transformation with ants
• CLI for applying a transformation using ants and cropping to overlapping region using Largest Internal Rectangle (LIR)

TODO:

• merge Registration refator #118 (need to push updates from fry2)
• test that registration works with keep_overhang: true @edyoshikun
• now that estimate_affine, optimize_affine, and apply_affine all take source and targets dirpaths, we no longer need to keep source_shape_zyx and target_shape_zyx in the yml config file @edyoshikun
• refactor registration and stabilization functions out of utils and into the registration and stabilization modules @ieivanov
• clean up function names @ieivanov
• update slurmkit examples
• link issues closed by this PR

Future PRs:

• rename target to fixed and source to moving to match convention in other image registration pipelines
• rename estimate-affine, optimize-affine, and apply-affine CLI calls to estimate-registration, optimize-registration, and register
• refactor process_single_position_v2 and apply_transform_to_zyx_and_save_v2 (and affine_transform) to work on arrays of consistent shape - either ZYX or CZYX, not both. Possibly move process_single_position and apply_transform_to_zyx_and_save to iohub (long with update_scale_metadata?). @talonchandler @ziw-liu
• try to find better cropping algorithm (maybe https://github.com/planetlabs/maxrect or https://shapely.readthedocs.io/en/stable/reference/shapely.intersection.html)
• check how apply_affine handles positions will all nans or zeros. Currently we convert nans to zeros, which should not be necessary

[ieivanov]

In the final version of the registration pipeline we should rotate the volumes by 90 deg such that they are in landscape mode rather than portrait mode (i.e. with larger width than height). Our brains process landscape aspect ratio more naturally and our monitors are built that way too. This is not critical now, but may affect some of the earlier design choices.

[edyoshikun]

@talonchandler let's schedule some time to go over this. Some design choices that we should also think about:

• Use scipy.ndimage vs ants registration
• What yaml config files should we take as input and output for the estimate-affine and optimize-affine.
• I don't want to complicate the functions to add the 90 deg rotation. If it's only for display, should we add this as a coordinateTransformMetadta()?

[talonchandler]

Excellent! @edyoshikun and I just finished a paired session and put together this list of (very superficial) TODO items. Thanks for all of your effort here @edyoshikun.

@edyoshikun I've tagged you on the ones that you're best suited to handle. I'll handle the rest.

• update -ls and -lf flag names to -s and -t
• @edyoshikun remove config from estimate-source-to-target-affine
• remove saving of .svgs from estimate-source-to-target-affine
• update optimize-affine docs, specify -o is YAML (edit: this is specified in the example docstring, so I think it's good)
• optimize-affine flags for display and channel choice
• @edyoshikun remove pre_affine_90degree... everywhere, handle output_shape parameter
• add -v flag for optimize-affine
• @edyoshikun add quick comment about how to move to scipy for GPU/cupy (not needed now)
• comment on landscape-mode results. Can napari's transpose provide the rotations we need without changing data storage conventions?