You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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?
The text was updated successfully, but these errors were encountered:
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
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.
@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.
@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.
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?
The text was updated successfully, but these errors were encountered: