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

.to_affine() aware of input and output axes #32

Closed
LucaMarconato opened this issue Oct 10, 2022 · 1 comment
Closed

.to_affine() aware of input and output axes #32

LucaMarconato opened this issue Oct 10, 2022 · 1 comment

Comments

@LucaMarconato
Copy link
Member

In this issue ome/ngff#146 I discuss a case in which affine transformations needed to be aware of the input and output coordinate systems in order to be specified, and I propose a solution to avoid this need and maintain the decoupling between coordinate systems and transformations.

Unfortunately this decoupling is not possible for those transformations types whose storage is not a description of the affine matrix itself (as it happens for instance for Affine, Translation, Scale, Rotation). Examples are Identity, MapIndex, MapAxis, Sequence.

Since for the visualization with napari we need an affine matrix, we need:

  1. to define a .to_affine() abstract method for the Transformation class and implement it to all the transformation types;
  2. pass input and output to .to_affine(), whenever this is necessary

The signature will be

    @abstractmethod
    def to_affine(self, input_axes: Optional[Tuple[str]] = None, output_axes: Optional[Tuple[str]] = None) -> Affine:
        pass
@LucaMarconato
Copy link
Member Author

I have addressed this. Now transformations have two more attributes: input_coordinate_system and output_coordinate_system. They can be None, but for calling to_affine() and transform_points() they need to be specified.

Some transformations could operate even when the input and output coordinate systems are not specified, like Identity, Translation, Scale, Rotation, but we enforce the explicit definition of input and output spaces.

Nevertheless, an edge cases from the specs allow the specification of transformations without making input and output spaces explicit when the transformations are part of a Sequence transformation. In the code, inside the Sequence, we are more restrictive: we try to infer the transformation, like if we combine Translation and Scale we know that we are operating all the time in the same input coordinate system of the Sequence transformation, but if we use Affine transformation inside the Sequence, we trigger an error since it's not clear which input and output axes are present. Same for MapAxis, input and output are required in order to know how it operates.

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

2 participants