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

proposal: x/image/draw: subpixel precision for image transformations #60722

Closed
lromor opened this issue Jun 10, 2023 · 4 comments
Closed

proposal: x/image/draw: subpixel precision for image transformations #60722

lromor opened this issue Jun 10, 2023 · 4 comments
Labels
Milestone

Comments

@lromor
Copy link

lromor commented Jun 10, 2023

When dealing with image transformations, sometimes it's necessary to refer to an image sub-pixel locations. Current API doesn't allow for any expression of such kind of transformations due to the representation of image.Point{} which only supports integer values.

Popular libraries in other languages support this semantics, for instance python Pillow:

https://pillow.readthedocs.io/en/stable/reference/Image.html#PIL.Image.Image.resize

Allows to specify a box from the source image using float values but enforces an integer set of pixels to sample the image to.
I believe for scaling the Pillow function signature is of greater value. What do you think?

@gopherbot gopherbot added this to the Proposal milestone Jun 10, 2023
@seankhliao seankhliao changed the title proposal: Image rectangle float affected/package: golang.org/x/image/draw proposal: x/image/draw: subpixel precision for image transformations Jun 10, 2023
@ianlancetaylor
Copy link
Contributor

Can you suggest new API that would implement this? Thanks.

CC @nigeltao

@lromor
Copy link
Author

lromor commented Jun 11, 2023

I would suggest changing all the functions with a similar signature:

Scale(dst Image, dr image.Rectangle, src image.Image, sr image.Rectangle, op Op, opts *Options)

Into something like:

Scale(dst Image, dr image.Rectangle, src image.Image, sr image.Rectangle[Number], op Op, opts *Options)

Or introduce an image.RectangleFloat to be used as type for the source rectangle of the image.
The idea is that during transformations, images have an intermediate 2d function representation. Although the output of a transformation is always an image (a set of sampled values in a 2d array), forcing the user to always sample on a grid that lies on integral numbers of the source domain seems to me restrictive.

@ianlancetaylor
Copy link
Contributor

@lromor Thanks, but we don't want to change any existing function, as that would break existing working programs that call that function. We can add new functions, but we can't change existing ones.

@lromor
Copy link
Author

lromor commented Jun 12, 2023

@ianlancetaylor , sorry for the fuss. I don't want to defend this proposal anymore. My conclusion is that the Transformer interface and relevant implementations are more than enough for my use case. One could make a case about the Scaler as well, but I'm not a fan of adding another function.

@lromor lromor closed this as completed Jun 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants