Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Review underlying axis alignment assumptions #17

Open
tbirdso opened this issue Nov 15, 2023 · 0 comments
Open

Review underlying axis alignment assumptions #17

tbirdso opened this issue Nov 15, 2023 · 0 comments

Comments

@tbirdso
Copy link
Collaborator

tbirdso commented Nov 15, 2023

Background

As an initial implementation the itk_dreg.block subpackage provides ease-of-use methods for mapping between voxel and physical spaces based on metadata from itk.Image, NumPy, and Dask region specifiers. In several cases the itk_dreg.block subpackage estimates axis-aligned bounding boxes in physical space to describe image domains.

Current Behavior

Axis-aligned bounding boxes may not be fully descriptive of image regions in several cases:

  • If the image direction matrix indicates axis rotation other than 90 degree increments, a bounding box composed from the corners of the image may fail to fully encompass image content in XYZ physical space.
  • If the image direction matrix describes nonorthogonal axes, it is not well defined how a bounding box may encompass image content. This case is not currently supported by itk-dreg (axes must be orthogonal).
  • If a generic transform is applied, image warping may result in a content region that cannot be well described by a bounding box.

Requested Behavior

Revisit the itk_dreg.register and itk_dreg.block submodules and consider the following:

  • Can we update itk_dreg.block methods to return oriented bounding boxes (unbuffered itk.Images) instead of assuming axis alignment?
  • Are there cases where other descriptors may be more appropriate to describe transformed image domains? Meshes, shape descriptors, etc? Perhaps adaptable for domain-specific use cases?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant