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

SpatialTransform with respect to different coordinate systems (Axes) #52

Open
schuhschuh opened this issue Jun 2, 2023 · 2 comments
Open
Labels
enhancement New feature or request p3-nice-to-have Priority level 3 - nice to have

Comments

@schuhschuh
Copy link
Member

Currently, a SpatialTransform is a coordinate mapping of normalized coordinates with respect to the reference sampling Grid specified when constructing the spatial transformation object. A user of the transform has to map coordinates with respect to other Axes to these normalized coordinates before applying the transformation, and back again. In contexts where no normalized coordinates are used to represent the spatial transformation because torch.nn.functional.grid_sample is not being utilized, one might even want to parameterize the spatial transformation with respect to other coordinate systems (e.g., the world coordinate system). These use cases could be supported by adding a axes: Axes property and optionally a corresponding keyword argument to SpatialTranform.forward(.., axes: Optional[Axes] = None) which can be used to define the parameterization axes of the coordinate map and further to specify with respect to which axes the input points are defined.

Thanks @qiuhuaqi for this suggestion. Let's discuss here benefits or any reason why we wouldn't support this.

@schuhschuh schuhschuh added the enhancement New feature or request label Jun 2, 2023
@aschuh-hf
Copy link
Collaborator

aschuh-hf commented Jun 24, 2023

While this feature request is different from #53, and may still be desirable for those who want to implement a classic registration which directly operates in world space rather than normalized point coordinates, a possible work-around is to use SpatialTransform.points() instead of having spatial transforms whose parameterization is with respect to unnormalized coordinates spaces.

See #62.

@aschuh-hf aschuh-hf added the p3-nice-to-have Priority level 3 - nice to have label Jun 24, 2023
@qiuhuaqi
Copy link
Collaborator

qiuhuaqi commented Jun 30, 2023

sorry I must've missed the review request for #62.
I can see this is a good workaround for my usecase, which is transforming the points which are in the un-normalised space (world space) with SpatialTransform.

For image registration operating in the world space, we can internally handle all the spatial normalisation to make sure everything is correct when SpatialTransform is being used. So it would be indeed a bit redundant. But it would be somehow cleaner IMO if the entire SpatialTransform module considers axes. For example, if one wants to collapse the transform to tensor format, I think SpatialTransform.tensor() method right now can only produce fields in the normalised space? It could just be enough to just add axes as an argument to any relevant functions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request p3-nice-to-have Priority level 3 - nice to have
Projects
None yet
Development

No branches or pull requests

3 participants