Intent to Ship: WebGL canvas color management

265 views
Skip to first unread message

Christopher Cameron

unread,
May 17, 2022, 6:39:59 PM5/17/22
to blink-dev

Contact emails

ccam...@chromium.org

Specification

This is part of the WebGL specification. In particular:

This spec was originally developed in the W3C's ColorWeb community group along with the 2D canvas color management proposal at

https://github.com/WICG/canvas-color-space/blob/main/CanvasColorSpaceProposal.md

It was broken out and iterated upon separately in Khronos (in particular by Mozilla and Chrome representatives). The final changes to the Khronos WebGL spec are in 

Summary

Implementation of WebGL color management API WebGL allows specification of - the color space that its drawing buffer is - the color space that content should be converted to when importing as a texture This feature is to update our implementation to include this functionality. Prior to this feature, both of these defaulted to sRGB. Now they can also use "display-p3".


Blink component

Blink>WebGL

Search tags

canvaswebgldisplay-p3color space

TAG review status

N/A. Canvas 2D color managment API already TAG reviewed at
This specification change was developed in Khronos and followed the processes there.

Risks



Interoperability and Compatibility



Gecko: Positive Developed in close collaboration with Mozilla, spec changes reviewed by Mozilla.

WebKit: Positive Discussed in ColorWeb CG with WebKit representatives

Web developers: Strongly positive

Other signals:

Privacy: N/A

This exposes no information about the user's system to the web. This API can be used on systems that do not support wide color gamut (the out-of-gamut colors are clipped, as they are for 2D canvas, images, and video).

Security: N/A

This allows a WebGL canvas to specify its color space. This functionality is already present for 2D canvas, images, and video content.



Debuggability

Debugging is currently limited to sRGB colors. This limits visibility into wide color gamut image, video, and 2D canvas. This limitation is being looked at in the context of adding CSS color level 4 support.



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

No, this is tested instead by WebGL conformance tests.

Flag name

WebGLColorManagement

Requires code in //chrome?

No

Tracking bug

https://crbug.com/1208480

Sample links

https://ccameron-chromium.github.io/webgl-examples/p3.html

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4814886323355648

Ken Russell

unread,
May 17, 2022, 7:35:22 PM5/17/22
to Christopher Cameron, blink-dev
LGTM not as API owner, but as member of Khronos' WebGL working group (and also the chair).

-Ken



--
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/CAGnfxj_6radHqyNz4Sxa3SxZET-93xJCdMdZe6WptHxOLyhC3A%40mail.gmail.com.

Rick Byers

unread,
May 18, 2022, 2:25:11 PM5/18/22
to Ken Russell, Christopher Cameron, blink-dev
This looks like a pretty straight forward small addition. Just a couple questions:
Any links? Apple and Mozilla have asked us to rely only on their official signals. Since they're broadly supportive of WebGL I doubt we really need to go file a full Mozilla standards position request. But some pointer would help. Any idea of implementation status in those engines?

Web developers: Strongly positive

Other signals:

Privacy: N/A

This exposes no information about the user's system to the web. This API can be used on systems that do not support wide color gamut (the out-of-gamut colors are clipped, as they are for 2D canvas, images, and video).

Security: N/A

This allows a WebGL canvas to specify its color space. This functionality is already present for 2D canvas, images, and video content.



Debuggability

Debugging is currently limited to sRGB colors. This limits visibility into wide color gamut image, video, and 2D canvas. This limitation is being looked at in the context of adding CSS color level 4 support.



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

No, this is tested instead by WebGL conformance tests.

Can you link to the specific tests? This is really intended to ask about automated conformance testing generally, sorry for my ignorance of how the WebGL conformance tests work. 


Flag name

WebGLColorManagement

Requires code in //chrome?

No

Tracking bug

https://crbug.com/1208480

Sample links

https://ccameron-chromium.github.io/webgl-examples/p3.html

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4814886323355648

--
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/CAGnfxj_6radHqyNz4Sxa3SxZET-93xJCdMdZe6WptHxOLyhC3A%40mail.gmail.com.

--
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.

Ken Russell

unread,
May 18, 2022, 2:48:51 PM5/18/22
to Rick Byers, Christopher Cameron, blink-dev
Mozilla reviewed and approved the additions of drawingBufferColorSpace and unpackColorSpace to the WebGL specification:

Mozilla has recently reported to Khronos' WebGL working group that they have P3 colorspace WebGL-rendered canvases rendering end-to-end on macOS. I'm afraid that due to IP agreements, these meeting minutes are not public. However, any employee of a Khronos member company (Apple, Google, Microsoft, and Mozilla all are) is welcome to create an account and see those meeting minutes. Let me know if you need a pointer.

The discussions in the W3C's ColorWeb community group, and summary minutes thereof, can be seen here:

I haven't yet found all of the meetings in which these WebGL-specific APIs were discussed, so don't immediately have public evidence of Apple's positive stance. Let me know if archaeology is needed. Note that Apple and WebKit have been at the forefront of adding wide color gamut support to CSS.


Web developers: Strongly positive

Other signals:

Privacy: N/A

This exposes no information about the user's system to the web. This API can be used on systems that do not support wide color gamut (the out-of-gamut colors are clipped, as they are for 2D canvas, images, and video).

Security: N/A

This allows a WebGL canvas to specify its color space. This functionality is already present for 2D canvas, images, and video content.



Debuggability

Debugging is currently limited to sRGB colors. This limits visibility into wide color gamut image, video, and 2D canvas. This limitation is being looked at in the context of adding CSS color level 4 support.



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

No, this is tested instead by WebGL conformance tests.

Can you link to the specific tests? This is really intended to ask about automated conformance testing generally, sorry for my ignorance of how the WebGL conformance tests work.

Yes, certainly. Here are Chris's initial tests exercising video uploads in the sRGB and P3 color spaces:

These can actually be run online here:

See the conformance/textures/video and conformance2/textures/video subtrees.

In Chromium these are a third_party dependency, and are run on the commit queue on physical machines containing GPUs.

-Ken

Chris Harrelson

unread,
May 18, 2022, 6:40:03 PM5/18/22
to Ken Russell, Rick Byers, Christopher Cameron, blink-dev
Hi, comments below.

On Wed, May 18, 2022 at 11:48 AM Ken Russell <k...@chromium.org> wrote:

On Tue, May 17, 2022 at 3:40 PM 'Christopher Cameron' via blink-dev <blin...@chromium.org> wrote:


TAG review status

N/A. Canvas 2D color managment API already TAG reviewed at

Should this intent reuse issue 646 then? Are the considerations and API almost exactly the same as in 2D canvas? Another option is to comment on that issue describing the WebGL variant of the same feature, and calling out the notable differences the TAG needs to be aware of to provide useful feedback.
 
This specification change was developed in Khronos and followed the processes there.

Risks



Interoperability and Compatibility



Gecko: Positive Developed in close collaboration with Mozilla, spec changes reviewed by Mozilla.

WebKit: Positive Discussed in ColorWeb CG with WebKit representatives

Please file for official signals. Participating in discussions is not the same as officially supporting.
 
Web developers: Strongly positive

Could you give examples of developer support?

Ken Russell

unread,
May 18, 2022, 7:04:22 PM5/18/22
to Chris Harrelson, Rick Byers, Christopher Cameron, blink-dev
I'd like to respectfully point out that this API was agreed upon by all major browser implementers in Khronos' WebGL working group, whose processes have been well established over the last decade. The WebGL working group owns the responsibility for evolving this portion of this web API, and the requirement in Blink's processes to fetch signals is causing duplicate work to be done in this context.

I would like to respectfully request that Blink's processes be changed to not require implementation signals for WebGL specification changes. Any such changes are already only made with full agreement among Gecko, WebKit and Blink engineers.


Web developers: Strongly positive

Could you give examples of developer support?

Not to speak for Chris Cameron, but this support was requested, with urgency, by Adobe.

-Ken

Chris Harrelson

unread,
May 18, 2022, 7:18:53 PM5/18/22
to Ken Russell, Rick Byers, Christopher Cameron, blink-dev
Got it, ok. We already have an exception in two cases, let's work together on adding it to bit.ly/blink-intents.
 


Web developers: Strongly positive

Could you give examples of developer support?

Not to speak for Chris Cameron, but this support was requested, with urgency, by Adobe.

-Ken

--
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.

Chris Harrelson

unread,
May 18, 2022, 7:19:34 PM5/18/22
to Ken Russell, Rick Byers, Christopher Cameron, blink-dev
On Wed, May 18, 2022 at 4:18 PM Chris Harrelson <chri...@chromium.org> wrote:


On Wed, May 18, 2022 at 4:04 PM Ken Russell <k...@chromium.org> wrote:
On Wed, May 18, 2022 at 3:40 PM Chris Harrelson <chri...@chromium.org> wrote:
Hi, comments below.

On Wed, May 18, 2022 at 11:48 AM Ken Russell <k...@chromium.org> wrote:

On Tue, May 17, 2022 at 3:40 PM 'Christopher Cameron' via blink-dev <blin...@chromium.org> wrote:


TAG review status

N/A. Canvas 2D color managment API already TAG reviewed at

Should this intent reuse issue 646 then? Are the considerations and API almost exactly the same as in 2D canvas? Another option is to comment on that issue describing the WebGL variant of the same feature, and calling out the notable differences the TAG needs to be aware of to provide useful feedback.
 
This specification change was developed in Khronos and followed the processes there.

Risks



Interoperability and Compatibility



Gecko: Positive Developed in close collaboration with Mozilla, spec changes reviewed by Mozilla.

WebKit: Positive Discussed in ColorWeb CG with WebKit representatives

Please file for official signals. Participating in discussions is not the same as officially supporting.

I'd like to respectfully point out that this API was agreed upon by all major browser implementers in Khronos' WebGL working group, whose processes have been well established over the last decade. The WebGL working group owns the responsibility for evolving this portion of this web API, and the requirement in Blink's processes to fetch signals is causing duplicate work to be done in this context.

I would like to respectfully request that Blink's processes be changed to not require implementation signals for WebGL specification changes. Any such changes are already only made with full agreement among Gecko, WebKit and Blink engineers.

Got it, ok. We already have an exception in two cases, let's work together on adding it to bit.ly/blink-intents.

...make that bit.ly/blink-signals.

Chris Harrelson

unread,
May 18, 2022, 7:41:32 PM5/18/22
to Ken Russell, Rick Byers, Christopher Cameron, blink-dev
I've updated bit.ly/blink-signals to include an exception for Khronos (see the document for details).

Thanks for the developer signal.

LGTM1 for this intent!

Yoav Weiss

unread,
May 19, 2022, 10:08:54 AM5/19/22
to blink-dev, Chris Harrelson, Rick Byers, Christopher Cameron, blink-dev, Kenneth Russell
LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Mike Taylor

unread,
May 19, 2022, 10:18:58 AM5/19/22
to Yoav Weiss, blink-dev, Chris Harrelson, Rick Byers, Christopher Cameron, Kenneth Russell
LGTM3
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/dc570756-2c4d-49f0-8a4a-05b11fd235e3n%40chromium.org.


Reply all
Reply to author
Forward
0 new messages