Skip to content

Conversation

@KumoLiu
Copy link
Contributor

@KumoLiu KumoLiu commented Feb 29, 2024

Part of #7486

Description

Geometric transform -- Resize

Types of changes

  • Non-breaking change (fix or new feature that would not break existing functionality).
  • Breaking change (fix or new feature that would cause existing functionality to change).
  • New tests added to cover the changes.
  • Integration tests passed locally by running ./runtests.sh -f -u --net --coverage.
  • Quick tests passed locally by running ./runtests.sh --quick --unittests --disttests.
  • In-line docstrings updated.
  • Documentation updated, tested make html command in the docs/ folder.

KumoLiu and others added 3 commits March 1, 2024 00:22
Signed-off-by: YunLiu <55491388+KumoLiu@users.noreply.github.com>
Signed-off-by: YunLiu <55491388+KumoLiu@users.noreply.github.com>
@KumoLiu KumoLiu added this to the Geometric Transform API milestone Mar 1, 2024
@KumoLiu KumoLiu self-assigned this Mar 1, 2024
KumoLiu added 3 commits March 6, 2024 18:40
Signed-off-by: YunLiu <55491388+KumoLiu@users.noreply.github.com>
Signed-off-by: YunLiu <55491388+KumoLiu@users.noreply.github.com>
Signed-off-by: YunLiu <55491388+KumoLiu@users.noreply.github.com>
return points_affine


def resize_point(points, out_size, dtype, input_ndim, lazy, transform_info, **kwargs):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How can we avoid having *_point(...) functions for each operation? At this level, shouldn't we be able to always just pass the correct transform? If we think about object space (raster space) and world space transforms then we shouldn't need to be performing these calculations based on spatial size here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I understand it, resize should have no effect on point data, as it is entirely a "raster" space operation that preserves the extents of an image or volume, no?

Copy link
Contributor

@atbenmurray atbenmurray Mar 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed in the meeting, the alternative of taking the operation that defines the operation out of the function and putting it into its own implementation function works just as well as what I am suggesting.

def resize_point(data, lazy, ...):
    meta_info = get_resize(...)
    out = apply_to_geom(data, metainfo, lazy)
    return out

def resize_image(data, lazy, ...):
    meta_info = get_resize(...)
    if not lazy:
        out = torch.interpolate(data, meta_info.affine)
    else:
        out = out.copy_meta_from(meta_info)
    return out

@atbenmurray atbenmurray mentioned this pull request Mar 8, 2024
7 tasks
KumoLiu added 2 commits May 30, 2024 15:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: In progress

Development

Successfully merging this pull request may close these issues.

2 participants