proposal: image: add image.NYCbCrA and color.NYCbCrA types.

[nigeltao]

This adds transparency (an Alpha channel) to the existing YCbCr types for JPEG-like images and color. The N stands for non-alpha-premultiplied, the same as the existing NRGBA types.

JPEG-like-with-alpha is used by the WebP format, and there already exists code (see [0]) under golang.org/x to represent such images and colors. The proposal is to move that from golang.org/x/image/webp/nycbcra to image, so that the image/draw package in the standard library can recognize such images, and implement a fast path for drawing them, the way YCbCr images are fast-pathed.

[0] https://go.googlesource.com/image/+/master/webp/nycbcra/nycbcra.go

[bradfitz]

SGTM. I don't think its inclusion would materially affect the display of https://golang.org/pkg/image/

[robpike]

SGTM

[gopherbot]

CL https://golang.org/cl/15671 mentions this issue.

[pierrre]

@nigeltao I have a question about this change:

In YCbCr.RGBA(), the code is a modified copy of YCbCrToRGB():

    // This code is a copy of the YCbCrToRGB function above, except that it
    // returns values in the range [0, 0xffff] instead of [0, 0xff]. There is a
    // subtle difference between doing this and having YCbCr satisfy the Color
    // interface by first converting to an RGBA. The latter loses some
    // information by going to and from 8 bits per channel.

But in NYCbCrA.RGBA(), YCbCrToRGB() is called, instead of a modified version.
Why don't we use the same code?
I think we lose some information here.

[nigeltao]

This question is now issue #13706.