CC @nigeltao

Note that the RGBAAt(x, y int) (r, g, b, a uint32) proposal conflicts with the existing func (p *RGBA) RGBAAt(x, y int) color.RGBA in the standard library's package image.

Perhaps add some interfaces to the standard library (and make its concrete image types implement them):

package image

type ImageV2 interface {
    Image
    // AtDotRGBA(x, y) is equivalent to At(x, y).RGBA() but it can be more
    // efficient, as it does not allocate an intermediate color.Color.
    AtDotRGBA(x, y int) (r, g, b, a uint32)
}

// or perhaps

type ImageV2 interface {
    Image
    // RGBA64At(x, y) is equivalent to At(x, y).RGBA(), after packing RGBA's
    // four uint32 return values into one color.RGBA64, but it can be more
    // efficient, as it does not allocate an intermediate color.Color.
    RGBA64At(x, y int) color.RGBA64
}

package draw

type ImageV2 interface {
    Image
    // SetRGBA64(x, y, c) is equivalent to Set(x, y, c) but it can be more
    // efficient, as it does not allocate an intermediate color.Color.
    SetRGBA64(x, y int, c color.RGBA64)
}

golang.org/x/image/draw obviously gets:

type ImageV2 = draw.ImageV2

Yeah, the names are horrible and inconsistent, but we're constrained by Go 1 backwards compatibility...

CC @dmitshur

@nigeltao
I had forgotten about image.RGBA.RGBAAt. Considering this, the RGBA64At(x, y int) color.RGBA64 interface does seem more appropriate.

Reading through it again, package image also has somewhat of a convention that would suggest a better name. The concrete image types are RGBA, Gray16, &c. whereas the interface types are Image and PalettedImage. So, it would be natural to add RGBA64Image.

Unless there are objections, tomorrow I will retitle and change this proposal to adding

// RGBA64Image is an image with pixels that can be transformed directly to
// RGBA64.
type RGBA64Image interface {
	// RGBA64At returns the RGBA64 color of the pixel at (x, y). It is
	// equivalent to calling At(x, y).RGBA() and converting the resulting
	// 32-bit channels to color.RGBA64, but it may avoid allocations from
	// converting concrete color types to the color.Color interface type.
	RGBA64At(x, y int) color.RGBA64
	Image
}

to package image, updating the concrete image types to implement it, adding a corresponding RGBA64Image interface to image/draw and x/image/draw, updating the concrete image types in package image to implement these interfaces, and implementing fast paths in image/draw and x/image/draw using these types.

Sounds good to me.

With the new fast paths, I'd only bother with:

• "image.RGBA64Image on draw.RGBA64Image"

and not e.g.

• "image.Image on draw.RGBA64Image" or
• "image.RGBA64Image on draw.Image"

I was about to submit a separate proposal to add additional fast paths to x/image/draw for more resampling destination types. This proposal would solve that and many more similar problems in a much more elegant way. Really hoping to see it come to fruition!

@ianlancetaylor as above (March 12), this proposal (affecting the std image package) Sounds Good To Me.

What's the formal process from here? Do I upgrade this issue from Proposals/Incoming to Proposals/Active?

Change https://golang.org/cl/311129 mentions this issue: image: add RGBA64Image interface

@nigeltao No, that move will be done when the proposal review committee gets to this issue.

I'll add it to the list to consider in the next meeting.

Seems OK. Adding to minutes.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

The CL was sent before the freeze. The proposal was also accepted roughly on the border of dev and freeze. Although the beta1 is out for few days, is there still a chance to get this in in the 1.17 release? So that we won't have to wait another 6 months?

Someone will have to review the CL.

Once that is done, you'll have to ask for a freeze exception. See https://groups.google.com/g/golang-dev/c/VNJFUxHWLHo/m/PBmGdYqoAAAJ .

The reviewers have since responded. I filed #46811 to discuss the freeze exception.

2 questions via #46688.

In the original proposal, it was suggested that:

I propose that the image types Alpha, Alpha16, CMYK, Gray, Gray16, NRGBA, NRGBA64, Paletted, and RGBA be extended to implement both of these interfaces (noting that RGBA64 already does), and that NYCbCrA, Uniform, and YCbCr be extended to implement the former.

CL 311129 implemented all of that, with the exception of image.Uniform.

@nigeltao Can you confirm leaving out Uniform is intentional and okay? (Asking this question for #46688.)

Also, the image/draw.RGBA64Image interface suggested in the proposal was:

type RGBA64Image interface {
	SetRGBA64(x, y int, c color.RGBA64)
	Image
}

CL 311129 implemented a slightly different one, which includes the RGBA64At(x, y int) color.RGBA64 method:

type RGBA64Image interface {
	image.RGBA64Image
	Set(x, y int, c color.Color)
	SetRGBA64(x, y int, c color.RGBA64)
}

I just want to point it out because it's a difference, and ask @nigeltao to confirm this is intentional and okay for purposes of #46688. Thanks.

(Everything else matches.)

Change https://golang.org/cl/331570 mentions this issue: image: add Uniform.RGBA64At and Rectangle.RGBA64At

@nigeltao Can you confirm leaving out Uniform is intentional and okay?

Leaving out image.Uniform in CL 311129 was unintentional.

On further thought, leaving out image.Rectangle (which implements image.Image) in both the CL and this proposal issue was an additional oversight.

My guiding principle is that, if a concrete image.Foo type previously implemented the image.Image interface, it should now also implement the image.RGBA64Image interface. Similarly, if it previously implemented the draw.Image interface, it should now also implement the draw.RGBA64Image interface.

I have sent out CL 331570 to address image.Uniform and image.Rectangle.

I just want to point it out [the interface definitions] because it's a difference, and ask @nigeltao to confirm this is intentional and okay

Yes, it's intentional that each draw.Foo interface is a superset of image.Foo (and for bar.QuxImage to be a superset of bar.Image). Sorry for the oversight in the proposal. Thanks for catching it. No further action required.

Change https://golang.org/cl/340049 mentions this issue: image/draw: add RGBA64Image fast path

Change https://golang.org/cl/351852 mentions this issue: image/draw: add RGBA64Image fast path for RGBA dst