Intent to deprecate and remove ImageDecoderInit.premultiplyAlpha.

62 views
Skip to first unread message

Dale Curtis

unread,
Sep 16, 2022, 5:19:11 PM9/16/22
to blink-dev, Christopher Cameron

Contact emails

dalec...@chromium.org

Explainer

None

Specification

https://github.com/w3c/webcodecs/issues/508

Summary

premultiplyAlpha tells ImageDecoder to multiply the alpha channel into the RGB channels of decoded images. It was added to mirror the capabilities of ImageBitmapOptions, but in retrospect doesn't make sense.

Feature has no observable effects in primary use cases (drawing), but may constrain implementations in suboptimal ways. E.g., requiring YUV be converted to RGB. See https://github.com/w3c/webcodecs/issues/508 for a more detailed description. Per consensus of WebCodecs spec editors and lack of usage (0.000000339% - 0.00000687% of page loads per a UseCounter in M105), we propose deprecating and removing this feature starting with M108.


Blink component

Blink>Media>WebCodecs

TAG review

Not applicable


TAG review status

Not applicable

Risks

It's possible that there exists some client which was accessing raw pixel data in JavaScript may observe that the alpha channel is no longer premultiplied into RGB channels. Clients wishing for this functionality can either do the multiply themselves or use createImageBitmap() to do this.


Interoperability and Compatibility



Gecko: Positive Firefox co-editor supports removal.

WebKit: No signal

Web developers: No signals

Other signals: Microsoft co-editor supports removal.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?


No.



Debuggability

n/a



Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

Flag name

n/a

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1340190

Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1340190

Estimated milestones

M108



Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

https://github.com/w3c/webcodecs/pull/562

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4560781148946432

This intent message was generated by Chrome Platform Status.

Christopher Cameron

unread,
Sep 19, 2022, 6:00:10 AM9/19/22
to Dale Curtis, blink-dev, Christopher Cameron
LGTM1

Yoav Weiss

unread,
Sep 20, 2022, 6:36:15 AM9/20/22
to Dale Curtis, blink-dev, Christopher Cameron
On Fri, Sep 16, 2022 at 11:19 PM Dale Curtis <dalec...@chromium.org> wrote:

Contact emails

dalec...@chromium.org

Explainer

None

Specification

https://github.com/w3c/webcodecs/issues/508

Summary

premultiplyAlpha tells ImageDecoder to multiply the alpha channel into the RGB channels of decoded images. It was added to mirror the capabilities of ImageBitmapOptions, but in retrospect doesn't make sense.

Feature has no observable effects in primary use cases (drawing), but may constrain implementations in suboptimal ways. E.g., requiring YUV be converted to RGB. See https://github.com/w3c/webcodecs/issues/508 for a more detailed description. Per consensus of WebCodecs spec editors and lack of usage (0.000000339% - 0.00000687% of page loads per a UseCounter in M105), we propose deprecating and removing this feature starting with M108.


What would breakage look like? What would happen to callers who still pass that option?
 


Blink component

Blink>Media>WebCodecs

TAG review

Not applicable


TAG review status

Not applicable

Risks

It's possible that there exists some client which was accessing raw pixel data in JavaScript may observe that the alpha channel is no longer premultiplied into RGB channels. Clients wishing for this functionality can either do the multiply themselves or use createImageBitmap() to do this.


Interoperability and Compatibility



Gecko: Positive Firefox co-editor supports removal.


I don't know if we can consider this a Mozilla position. At the same time, this seems small enough to not warrant an explicit issue. (and it's good to have consensus on the issue)
  
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPUDrwc%3D7%2B2KC73kKTUdWUmvQNubFtZGphhh8DXgQXnr%2BJc_LQ%40mail.gmail.com.

Dale Curtis

unread,
Sep 20, 2022, 2:10:36 PM9/20/22
to Yoav Weiss, blink-dev, Christopher Cameron
On Tue, Sep 20, 2022 at 3:36 AM Yoav Weiss <yoav...@chromium.org> wrote:


On Fri, Sep 16, 2022 at 11:19 PM Dale Curtis <dalec...@chromium.org> wrote:

Contact emails

dalec...@chromium.org

Explainer

None

Specification

https://github.com/w3c/webcodecs/issues/508

Summary

premultiplyAlpha tells ImageDecoder to multiply the alpha channel into the RGB channels of decoded images. It was added to mirror the capabilities of ImageBitmapOptions, but in retrospect doesn't make sense.

Feature has no observable effects in primary use cases (drawing), but may constrain implementations in suboptimal ways. E.g., requiring YUV be converted to RGB. See https://github.com/w3c/webcodecs/issues/508 for a more detailed description. Per consensus of WebCodecs spec editors and lack of usage (0.000000339% - 0.00000687% of page loads per a UseCounter in M105), we propose deprecating and removing this feature starting with M108.


What would breakage look like? What would happen to callers who still pass that option?

If they're just drawing the frames into canvas, webgl, etc there is no observable difference or breakage (this is the common use case) - since the draw stage takes care of any alpha blending. If they're accessing the raw pixels via VideoFrame::copyTo() they would notice that the alpha is no longer premultiplied. Depending on what the application is doing with the frames this may mean nothing (i.e., not using images w/ alpha, or didn't care about alpha) or it could result in color changes in the image.
 
 


Blink component

Blink>Media>WebCodecs

TAG review

Not applicable


TAG review status

Not applicable

Risks

It's possible that there exists some client which was accessing raw pixel data in JavaScript may observe that the alpha channel is no longer premultiplied into RGB channels. Clients wishing for this functionality can either do the multiply themselves or use createImageBitmap() to do this.


Interoperability and Compatibility



Gecko: Positive Firefox co-editor supports removal.


I don't know if we can consider this a Mozilla position. At the same time, this seems small enough to not warrant an explicit issue. (and it's good to have consensus on the issue)

That's a bit surprising. I think that's a pretty strong signal, but defer to the API owners.

Yoav Weiss

unread,
Sep 21, 2022, 7:44:37 AM9/21/22
to Dale Curtis, blink-dev, Christopher Cameron
LGTM1

It seems unlikely that even the (few) developers who access this data are somehow relying on it.  

That's a strong signal from the person editing the spec, but not an official Mozilla position.

Mike Taylor

unread,
Sep 21, 2022, 11:25:52 AM9/21/22
to Yoav Weiss, Dale Curtis, blink-dev, Christopher Cameron

Philip Jägenstedt

unread,
Sep 21, 2022, 11:44:03 AM9/21/22
to Mike Taylor, Yoav Weiss, Dale Curtis, blink-dev, Christopher Cameron
LGTM3, to remove in 108 without deprecation period.

Dale Curtis

unread,
Sep 21, 2022, 5:14:36 PM9/21/22
to Philip Jägenstedt, Mike Taylor, Yoav Weiss, blink-dev, Christopher Cameron
Reply all
Reply to author
Forward
0 new messages