Intent to Ship: Canvas color management

[Christopher Cameron]

Contact emails

ccam...@google.com, yi...@google.com, fs...@google.com, ju...@google.com

Explainer

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

Specification

https://github.com/whatwg/html/pull/6562 (already merged)

API spec

Yes

Summary

Formalize that the default color space for 2D canvases and ImageData is sRGB. Clarify that 2D canvas is fully color managed (that all inputs are converted to the canvas color space). These were previously convention and not clearly specified. Add parameters to specify a non-sRGB color space when creating a 2D canvas or an ImageData. Add support for the Display P3 color space for these parameters.

Blink component

Blink

Search tags

canvas, display-p3, color space

TAG review

None. This spec was developed and discussed at great length in the W3C's ColorWeb CG.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Compatibility: This formalizes existing browser behaviors in spec. All new behaviors in this spec are explicitly "opt-in". No web content should break because of this change (if it does, it's a bug). Interoperability: Other browsers have indicated a strong intent to ship this feature as well. In the absence of this feature, content is still visible to the user, but with a limited color gamut.

Gecko: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1703654) This spec has been developed in close cooperation with Mozilla engineers.

WebKit: In development (https://bugs.webkit.org/show_bug.cgi?id=225140) Patches started landing against the bug immediately after it was filed.

Web developers: No signals

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

Yes

Flag name

CanvasColorManagement

Tracking bug

https://crbug.com/1083693

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5807007661555712

Links to previous Intent discussions

Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/YKH6RSab_vY/m/nylTA4NZAwAJ

[Yoav Weiss]

Thanks for working on this, this is exciting!!

If you know it, can you provide a reminder of the status of the rest of the platform when it comes to color management? (I dug into that many years ago, but I'm guessing/hoping things have significantly changed since)

Specific questions that come to mind:

• What's the status of colors in CSS? It seems like Safari has shipped P3 support. Have we? If not, are we correctly correcting colors when displaying them in non-sRGB displays?
• Are images with ICC profiles properly displayed in the right color space on all platforms?
• Are images without ICC profiles assumed to be sRGB and properly corrected to the screen's color space?
• What's the situation with videos?

The reason I'm asking all the above is that correcting one of these without the others can result in visual disparity and degraded user experience. So I'd like to better understand where we're at on that front.

On Tue, Jun 8, 2021 at 11:37 PM 'Christopher Cameron' via blink-dev <blin...@chromium.org> wrote:

Contact emails

ccam...@google.com, yi...@google.com, fs...@google.com, ju...@google.com

Explainer

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

Specification

https://github.com/whatwg/html/pull/6562 (already merged)

API spec

Yes

Summary

Formalize that the default color space for 2D canvases and ImageData is sRGB. Clarify that 2D canvas is fully color managed (that all inputs are converted to the canvas color space). These were previously convention and not clearly specified. Add parameters to specify a non-sRGB color space when creating a 2D canvas or an ImageData. Add support for the Display P3 color space for these parameters.

Blink component

Blink

Search tags

canvas, display-p3, color space

TAG review

None. This spec was developed and discussed at great length in the W3C's ColorWeb CG.

I appreciate the lengthy CG discussion, but I don't believe it's a replacement for a TAG review of the feature. That is doubly relevant in an area with so many moving parts as color management.

 

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Compatibility: This formalizes existing browser behaviors in spec. All new behaviors in this spec are explicitly "opt-in". No web content should break because of this change (if it does, it's a bug).

That's reassuring when it comes to my questions above. At the same time, it could still mean developers may ship new code that "works on their machine", but looks bad in some random color space.

Have y'all worked with DevTools folks to see if e.g. color space emulation mode may be something we want to add to prevent such a scenario? Or alternatively add alerts (to DevTools/LightHouse) when we see that different color spaces will be mixed together in potentially-jarring ways?

 

Interoperability: Other browsers have indicated a strong intent to ship this feature as well. In the absence of this feature, content is still visible to the user, but with a limited color gamut.

What's the feature detection story for this?

 

Gecko: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1703654) This spec has been developed in close cooperation with Mozilla engineers.

Spec involvement doesn't imply commitment or endorsement. 

At the same time, it seems that Mozilla has already provided commitment as part of the HTML PR, so we may want to skip asking for a position.

+Anne van Kesteren - do you agree?

WebKit: In development (https://bugs.webkit.org/show_bug.cgi?id=225140) Patches started landing against the bug immediately after it was filed.

Agree that this looks promising. Officially, we're supposed to ask for an official position (bit.ly/blink-signals). It may make sense to make an exception in such cases though. 

+Chris Harrelson - thoughts on this and the Mozilla case above?

Web developers: No signals

Have you reached out? Who will use this if we ship this?

This ran through an OT - have you had any meaningful developer feedback as a result?

See goo.gle/developer-signals 

 

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

Yes

Flag name

CanvasColorManagement

Tracking bug

https://crbug.com/1083693

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5807007661555712

Links to previous Intent discussions

Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/YKH6RSab_vY/m/nylTA4NZAwAJ

--
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-6d_hNstLr1oRcmK4rtYXik8sE7_bGpHSZLmRxusimWg%40mail.gmail.com.

[Yoav Weiss]

On Wed, Jun 9, 2021 at 8:45 AM Christopher Cameron <ccam...@google.com> wrote:

On Tue, Jun 8, 2021 at 10:13 PM Yoav Weiss <yoav...@chromium.org> wrote:

Thanks for working on this, this is exciting!!

If you know it, can you provide a reminder of the status of the rest of the platform when it comes to color management? (I dug into that many years ago, but I'm guessing/hoping things have significantly changed since)

Things have changed since that thread!!

For a couple of years now, it has been the case that all content has a well-defined color space. When that content is drawn to the screen, it is converted from "whatever space it is in" to "the output device's color space". The conversion algorithm is "relative colorimetric intent", which roughly means "don't do anything fancy" -- if the content specifies a color that the device can't show, just clamp to the nearest color that the device can show (where "nearest" is defined in a very simple way). The page can query the capabilities of the display using the gamut media query.

Canvas elements are (and have been for a few years) treated as being in sRGB. This means that if you draw a wide color gamut image to a canvas, it will lose detail (it will look like the thing on the left in this demo).

With that as the stage, what this feature adds is the ability to not lose detail in this way when using a 2D canvas.

 

Specific questions that come to mind:

• What's the status of colors in CSS? It seems like Safari has shipped P3 support. Have we? If not, are we correctly correcting colors when displaying them in non-sRGB displays?

All CSS colors are defined as being in sRGB, except the new ones in color level 4. Chrome doesn't support color level 4, but we'd like to add support soon.

• Are images with ICC profiles properly displayed in the right color space on all platforms?

Yes, images are converted to the display's color space using relative colorimetric intent, as specified by the ICC profile. Of note is that some platforms (Android) sometimes lie about the display's color space (they over-saturate things), but that distortion is done at the OS level, and the browser is just like any other app.

 

• Are images without ICC profiles assumed to be sRGB and properly corrected to the screen's color space?

Yes, the spec is now unambiguous about that.

 

• What's the situation with videos?

Videos are converted like images are.

There remains some ambiguity about how some videos are interpreted (e.g, if you use Apple's hardware decoder, you'll get frames that claim they're in color space A, but if you use ffmpeg or libvpx, you'll get frames that claim they're in space B, and if you use Window's media frameworks, the frames will say they're in space C). In all cases A, B, and C are very close (they have slightly different gamma values), and it's something I'd like to nail down in future spec work.

 

The reason I'm asking all the above is that correcting one of these without the others can result in visual disparity and degraded user experience. So I'd like to better understand where we're at on that front.

At this point the platform has moved to a very well-defined and capable place, and 2D canvas is lagging behind.

In particular, canvas is lagging behind because all content that is displayed in a canvas is clamped to sRGB color space. This proposal adds a mechanism to make the canvas clamp to Display P3 (which is wider) instead. In effect, it is allowing a canvas to do what Images and Videos have been able to do for a long time.

Thanks for the update!! It's great to hear we caught up on most of the debt in that space.

 

 

On Tue, Jun 8, 2021 at 11:37 PM 'Christopher Cameron' via blink-dev <blin...@chromium.org> wrote:

Contact emails

ccam...@google.com, yi...@google.com, fs...@google.com, ju...@google.com

Explainer

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

Specification

https://github.com/whatwg/html/pull/6562 (already merged)

API spec

Yes

Summary

Formalize that the default color space for 2D canvases and ImageData is sRGB. Clarify that 2D canvas is fully color managed (that all inputs are converted to the canvas color space). These were previously convention and not clearly specified. Add parameters to specify a non-sRGB color space when creating a 2D canvas or an ImageData. Add support for the Display P3 color space for these parameters.

Blink component

Blink

Search tags

canvas, display-p3, color space

TAG review

None. This spec was developed and discussed at great length in the W3C's ColorWeb CG.

I appreciate the lengthy CG discussion, but I don't believe it's a replacement for a TAG review of the feature. That is doubly relevant in an area with so many moving parts as color management.

I'll have to circle back with the places this suggestion came from (although the expanded above explanation may clarify the very narrow scope of this change).

 

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Compatibility: This formalizes existing browser behaviors in spec. All new behaviors in this spec are explicitly "opt-in". No web content should break because of this change (if it does, it's a bug).

That's reassuring when it comes to my questions above. At the same time, it could still mean developers may ship new code that "works on their machine", but looks bad in some random color space.

Have y'all worked with DevTools folks to see if e.g. color space emulation mode may be something we want to add to prevent such a scenario? Or alternatively add alerts (to DevTools/LightHouse) when we see that different color spaces will be mixed together in potentially-jarring ways?

Because of how things are well-defined, it's unlikely that appearance will change in an unexpected way across displays.

Probably the biggest concern would be someone who designs a page on a very capable display, that then gets crushed into something sort-of-washed-out-with-detail-missing when viewed on a less capable display. This is an interesting problem (and exists today in that one can trigger the same problem with a regular <img> element). I could imagine having a "please display this page as though it were on a weaker display" emulation mode being useful. I think that a "please emulate a better display" mode would be harder to do (at both a conceptual and implementation level).

Yeah, I'm more concerned about the "developer on a capable display, oblivious to the weak display experience" case.

Not a blocker here IMO, but worthwhile to run it with the devtools folks.

^^ +Paul Lewis +Mathias Bynens  

 

 

Interoperability: Other browsers have indicated a strong intent to ship this feature as well. In the absence of this feature, content is still visible to the user, but with a limited color gamut.

What's the feature detection story for this?

The color gamut media query can be used to determine if the display device will actually display the wider color gamut.

The color space of a 2D canvas is indicated in its CanvasRenderingContext2DSettings. If CanvasRenderingContext2DSettings has no colorSpace entry, then all canvases are sRGB by default.

Can developers detect support for e.g. P3 canvas color space support, and if it's not supported do something differently? (e.g. adjust their CSS or images to match sRGB)

Would they be able to detect support for Rec2020 if/when one is added?

On the code front, it seems like "colorSpace" is not behind the CanvasColorManagement flag. Is there a different flag that makes sure it's not already web exposed?

 

Gecko: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1703654) This spec has been developed in close cooperation with Mozilla engineers.

Spec involvement doesn't imply commitment or endorsement. 

At the same time, it seems that Mozilla has already provided commitment as part of the HTML PR, so we may want to skip asking for a position.

+Anne van Kesteren - do you agree?

WebKit: In development (https://bugs.webkit.org/show_bug.cgi?id=225140) Patches started landing against the bug immediately after it was filed.

Agree that this looks promising. Officially, we're supposed to ask for an official position (bit.ly/blink-signals). It may make sense to make an exception in such cases though. 

+Chris Harrelson - thoughts on this and the Mozilla case above?

Web developers: No signals

Have you reached out? Who will use this if we ship this?

Yes, I'm being a bit vague because I'm very hesitant to speak for partners. I'll get someone to circle back on this.

 

This ran through an OT - have you had any meaningful developer feedback as a result?

The initial proposal was more expansive in its features than what we decided to ship. The decision to remove all of the "extra stuff" came from the feedback that there wasn't as much demand for it. (In particular, there was a whole high-bit-depth feature, but that turned out to not have much traction outside of HDR work, which has built-on-top-of-this proposals).

(BTW, there were some issues with the OT, where many people who thought they were using the OT were actually enabling the feature via flags, and we didn't find out until later on in the game).

[Chris Harrelson]

I think it would be acceptable to add this into the existing Canvas API TAG review. There is one other color-related feature being discussed there that is relevant. This feature does need a TAG review one way or the other.

 

 

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Compatibility: This formalizes existing browser behaviors in spec. All new behaviors in this spec are explicitly "opt-in". No web content should break because of this change (if it does, it's a bug).

That's reassuring when it comes to my questions above. At the same time, it could still mean developers may ship new code that "works on their machine", but looks bad in some random color space.

Have y'all worked with DevTools folks to see if e.g. color space emulation mode may be something we want to add to prevent such a scenario? Or alternatively add alerts (to DevTools/LightHouse) when we see that different color spaces will be mixed together in potentially-jarring ways?

Because of how things are well-defined, it's unlikely that appearance will change in an unexpected way across displays.

Probably the biggest concern would be someone who designs a page on a very capable display, that then gets crushed into something sort-of-washed-out-with-detail-missing when viewed on a less capable display. This is an interesting problem (and exists today in that one can trigger the same problem with a regular <img> element). I could imagine having a "please display this page as though it were on a weaker display" emulation mode being useful. I think that a "please emulate a better display" mode would be harder to do (at both a conceptual and implementation level).

Yeah, I'm more concerned about the "developer on a capable display, oblivious to the weak display experience" case.

Not a blocker here IMO, but worthwhile to run it with the devtools folks.

^^ +Paul Lewis +Mathias Bynens  

 

 

Interoperability: Other browsers have indicated a strong intent to ship this feature as well. In the absence of this feature, content is still visible to the user, but with a limited color gamut.

What's the feature detection story for this?

The color gamut media query can be used to determine if the display device will actually display the wider color gamut.

The color space of a 2D canvas is indicated in its CanvasRenderingContext2DSettings. If CanvasRenderingContext2DSettings has no colorSpace entry, then all canvases are sRGB by default.

Can developers detect support for e.g. P3 canvas color space support, and if it's not supported do something differently? (e.g. adjust their CSS or images to match sRGB)

Would they be able to detect support for Rec2020 if/when one is added?

On the code front, it seems like "colorSpace" is not behind the CanvasColorManagement flag. Is there a different flag that makes sure it's not already web exposed?

 

Gecko: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1703654) This spec has been developed in close cooperation with Mozilla engineers.

Spec involvement doesn't imply commitment or endorsement. 

At the same time, it seems that Mozilla has already provided commitment as part of the HTML PR, so we may want to skip asking for a position.

+Anne van Kesteren - do you agree?

Jeff Gilbert from Mozilla approved the spec commit, I think this is enough.

 

WebKit: In development (https://bugs.webkit.org/show_bug.cgi?id=225140) Patches started landing against the bug immediately after it was filed.

Agree that this looks promising. Officially, we're supposed to ask for an official position (bit.ly/blink-signals). It may make sense to make an exception in such cases though. 

+Chris Harrelson - thoughts on this and the Mozilla case above?

Please just send an email to webkit-dev similar to this one.

 

Web developers: No signals

Have you reached out? Who will use this if we ship this?

Yes, I'm being a bit vague because I'm very hesitant to speak for partners. I'll get someone to circle back on this.

 

This ran through an OT - have you had any meaningful developer feedback as a result?

The initial proposal was more expansive in its features than what we decided to ship. The decision to remove all of the "extra stuff" came from the feedback that there wasn't as much demand for it. (In particular, there was a whole high-bit-depth feature, but that turned out to not have much traction outside of HDR work, which has built-on-top-of-this proposals).

(BTW, there were some issues with the OT, where many people who thought they were using the OT were actually enabling the feature via flags, and we didn't find out until later on in the game).

 

See goo.gle/developer-signals 

 

 

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

Yes

Flag name

CanvasColorManagement

Tracking bug

https://crbug.com/1083693

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5807007661555712

Links to previous Intent discussions

Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/YKH6RSab_vY/m/nylTA4NZAwAJ

--
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-6d_hNstLr1oRcmK4rtYXik8sE7_bGpHSZLmRxusimWg%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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUcFx33qZEHg4SLzoFYHBbc-t-%3Dy%3Dki1VW3cjwFd3xZqg%40mail.gmail.com.

[Christopher Cameron]

On Tue, Jun 8, 2021 at 10:13 PM Yoav Weiss <yoav...@chromium.org> wrote:

Thanks for working on this, this is exciting!!

If you know it, can you provide a reminder of the status of the rest of the platform when it comes to color management? (I dug into that many years ago, but I'm guessing/hoping things have significantly changed since)

Things have changed since that thread!!

For a couple of years now, it has been the case that all content has a well-defined color space. When that content is drawn to the screen, it is converted from "whatever space it is in" to "the output device's color space". The conversion algorithm is "relative colorimetric intent", which roughly means "don't do anything fancy" -- if the content specifies a color that the device can't show, just clamp to the nearest color that the device can show (where "nearest" is defined in a very simple way). The page can query the capabilities of the display using the gamut media query.

Canvas elements are (and have been for a few years) treated as being in sRGB. This means that if you draw a wide color gamut image to a canvas, it will lose detail (it will look like the thing on the left in this demo).

With that as the stage, what this feature adds is the ability to not lose detail in this way when using a 2D canvas.

 

Specific questions that come to mind:

• What's the status of colors in CSS? It seems like Safari has shipped P3 support. Have we? If not, are we correctly correcting colors when displaying them in non-sRGB displays?

All CSS colors are defined as being in sRGB, except the new ones in color level 4. Chrome doesn't support color level 4, but we'd like to add support soon.

• Are images with ICC profiles properly displayed in the right color space on all platforms?

Yes, images are converted to the display's color space using relative colorimetric intent, as specified by the ICC profile. Of note is that some platforms (Android) sometimes lie about the display's color space (they over-saturate things), but that distortion is done at the OS level, and the browser is just like any other app.

 

• Are images without ICC profiles assumed to be sRGB and properly corrected to the screen's color space?

Yes, the spec is now unambiguous about that.

 

• What's the situation with videos?

Videos are converted like images are.

There remains some ambiguity about how some videos are interpreted (e.g, if you use Apple's hardware decoder, you'll get frames that claim they're in color space A, but if you use ffmpeg or libvpx, you'll get frames that claim they're in space B, and if you use Window's media frameworks, the frames will say they're in space C). In all cases A, B, and C are very close (they have slightly different gamma values), and it's something I'd like to nail down in future spec work.

 

The reason I'm asking all the above is that correcting one of these without the others can result in visual disparity and degraded user experience. So I'd like to better understand where we're at on that front.

At this point the platform has moved to a very well-defined and capable place, and 2D canvas is lagging behind.

In particular, canvas is lagging behind because all content that is displayed in a canvas is clamped to sRGB color space. This proposal adds a mechanism to make the canvas clamp to Display P3 (which is wider) instead. In effect, it is allowing a canvas to do what Images and Videos have been able to do for a long time.

 

On Tue, Jun 8, 2021 at 11:37 PM 'Christopher Cameron' via blink-dev <blin...@chromium.org> wrote:

Contact emails

ccam...@google.com, yi...@google.com, fs...@google.com, ju...@google.com

Explainer

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

Specification

https://github.com/whatwg/html/pull/6562 (already merged)

API spec

Yes

Summary

Formalize that the default color space for 2D canvases and ImageData is sRGB. Clarify that 2D canvas is fully color managed (that all inputs are converted to the canvas color space). These were previously convention and not clearly specified. Add parameters to specify a non-sRGB color space when creating a 2D canvas or an ImageData. Add support for the Display P3 color space for these parameters.

Blink component

Blink

Search tags

canvas, display-p3, color space

TAG review

None. This spec was developed and discussed at great length in the W3C's ColorWeb CG.

I appreciate the lengthy CG discussion, but I don't believe it's a replacement for a TAG review of the feature. That is doubly relevant in an area with so many moving parts as color management.

I'll have to circle back with the places this suggestion came from (although the expanded above explanation may clarify the very narrow scope of this change).

 

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Compatibility: This formalizes existing browser behaviors in spec. All new behaviors in this spec are explicitly "opt-in". No web content should break because of this change (if it does, it's a bug).

That's reassuring when it comes to my questions above. At the same time, it could still mean developers may ship new code that "works on their machine", but looks bad in some random color space.

Have y'all worked with DevTools folks to see if e.g. color space emulation mode may be something we want to add to prevent such a scenario? Or alternatively add alerts (to DevTools/LightHouse) when we see that different color spaces will be mixed together in potentially-jarring ways?

Because of how things are well-defined, it's unlikely that appearance will change in an unexpected way across displays.

Probably the biggest concern would be someone who designs a page on a very capable display, that then gets crushed into something sort-of-washed-out-with-detail-missing when viewed on a less capable display. This is an interesting problem (and exists today in that one can trigger the same problem with a regular <img> element). I could imagine having a "please display this page as though it were on a weaker display" emulation mode being useful. I think that a "please emulate a better display" mode would be harder to do (at both a conceptual and implementation level).

 

 

Interoperability: Other browsers have indicated a strong intent to ship this feature as well. In the absence of this feature, content is still visible to the user, but with a limited color gamut.

What's the feature detection story for this?

The color gamut media query can be used to determine if the display device will actually display the wider color gamut.

The color space of a 2D canvas is indicated in its CanvasRenderingContext2DSettings. If CanvasRenderingContext2DSettings has no colorSpace entry, then all canvases are sRGB by default.

Gecko: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1703654) This spec has been developed in close cooperation with Mozilla engineers.

Spec involvement doesn't imply commitment or endorsement. 

At the same time, it seems that Mozilla has already provided commitment as part of the HTML PR, so we may want to skip asking for a position.

+Anne van Kesteren - do you agree?

WebKit: In development (https://bugs.webkit.org/show_bug.cgi?id=225140) Patches started landing against the bug immediately after it was filed.

Agree that this looks promising. Officially, we're supposed to ask for an official position (bit.ly/blink-signals). It may make sense to make an exception in such cases though. 

+Chris Harrelson - thoughts on this and the Mozilla case above?

Web developers: No signals

Have you reached out? Who will use this if we ship this?

Yes, I'm being a bit vague because I'm very hesitant to speak for partners. I'll get someone to circle back on this.

 

This ran through an OT - have you had any meaningful developer feedback as a result?

The initial proposal was more expansive in its features than what we decided to ship. The decision to remove all of the "extra stuff" came from the feedback that there wasn't as much demand for it. (In particular, there was a whole high-bit-depth feature, but that turned out to not have much traction outside of HDR work, which has built-on-top-of-this proposals).

(BTW, there were some issues with the OT, where many people who thought they were using the OT were actually enabling the feature via flags, and we didn't find out until later on in the game).

 

See goo.gle/developer-signals 

[Christopher Cameron]

On Wed, Jun 9, 2021 at 10:22 AM Chris Harrelson <chri...@chromium.org> wrote:

I think it would be acceptable to add this into the existing Canvas API TAG review. There is one other color-related feature being discussed there that is relevant. This feature does need a TAG review one way or the other.

I filed a separate TAG review at https://github.com/w3ctag/design-reviews/issues/646

 

Please just send an email to webkit-dev similar to this one.

Sent at https://lists.webkit.org/pipermail/webkit-dev/2021-June/031895.html

(after several tries of setting email headers correctly...)

[Yoav Weiss]

On Thu, Jun 10, 2021 at 3:52 AM Christopher Cameron <ccam...@google.com> wrote:

On Wed, Jun 9, 2021 at 12:23 AM Yoav Weiss <yoav...@chromium.org> wrote:

To clarify about matching -- because the 2D canvas is managed, images and CSS colors will always match (up to to clamping) in a P3 space versus a sRGB space -- there is no way to specify "raw" pixel values.

The topic of how to expose the color spaces had quite a bit of discussion in WhatWG and landed on using an enum, so the IDL will throw if an invalid enum value is used.

 

On the code front, it seems like "colorSpace" is not behind the CanvasColorManagement flag. Is there a different flag that makes sure it's not already web exposed?

Sorry, there was some confusion there, I'm cleaning it up (CanvasColorManagement covered a number of features, and I moved the "stuff from the OT that was cut"  behind the flag).

In that case what you should have done is add another flag, rather than expose the feature directly.

IIUC, this landed before the M92 branch, which is not great. Can you please revert that change (or add a new experimental flag) and merge that back to M92?

[Yoav Weiss]

On Thu, Jun 10, 2021 at 3:52 AM Christopher Cameron <ccam...@google.com> wrote:

On Wed, Jun 9, 2021 at 12:23 AM Yoav Weiss <yoav...@chromium.org> wrote:

To clarify about matching -- because the 2D canvas is managed, images and CSS colors will always match (up to to clamping) in a P3 space versus a sRGB space -- there is no way to specify "raw" pixel values.

 

Let's say that as a developer, I want to load a P3 image to canvas and then modify it in some way. I also want the image next to it to have matching a color space with the one loaded into the canvas. I understand that if we load one as P3 and the other as sRGB, conversions would mean that colors won't be completely off, but I suspect that clamping of the sRGB one could be meaningful. Is my suspicion correct?

Assuming it is, if the canvas is color managed (let's say, in Chromium once you've shipped this), I can load those 2 images as P3 ones.

If the canvas is not color managed at all (e.g. on an old version of Chromium), then the one drawn to canvas would be converted to sRGB, resulting in clamping. If so, I probably want to load the 2 images as sRGB.

For me to do that, I need to be able to feature-detect whether the canvas is color managed or not. How can I do that?

The topic of how to expose the color spaces had quite a bit of discussion in WhatWG and landed on using an enum, so the IDL will throw if an invalid enum value is used.

I think that answers my next question - how can we do the same for future color spaces? IIUC, you're saying that this would be addressed by catching such exceptions.

 

On the code front, it seems like "colorSpace" is not behind the CanvasColorManagement flag. Is there a different flag that makes sure it's not already web exposed?

Sorry, there was some confusion there, I'm cleaning it up (CanvasColorManagement covered a number of features, and I moved the "stuff from the OT that was cut"  behind the flag).

 

[Yoav Weiss]

On Thu, Jun 10, 2021 at 8:22 AM Christopher Cameron <ccam...@google.com> wrote:

Yes. Maybe a simpler "demo" of this situation is:

• A <canvas> next to <img>
• The source of the <img> is a P3 image
• The source of <img> is also drawn into <canvas> (I'll just say with no modifications, for simplicity)
• Are the <canvas> and the <img> identical?

Indeed, the "clamping to sRGB" will be exactly what happens to the right side of the screen in that demo. It will be a noticeable change on a non-sRGB display.

 

Assuming it is, if the canvas is color managed (let's say, in Chromium once you've shipped this), I can load those 2 images as P3 ones.

If the canvas is not color managed at all (e.g. on an old version of Chromium), then the one drawn to canvas would be converted to sRGB, resulting in clamping. If so, I probably want to load the 2 images as sRGB.

For me to do that, I need to be able to feature-detect whether the canvas is color managed or not. How can I do that?

This can be done by querying the CanvasRenderingContext2DSettings and seeing if there exists a colorSpace member (if not, then the feature is absent). I have a worked example here (it is written against an older version of the proposal from last year, which had a bunch of other features).

Cool, thanks for clarifying! I think it's important to outline that feature detection capability in the explainer and in general documentation of the feature.

 

(Slight terminology nit -- 2D canvas has been color managed for a couple of years, it just hasn't been documented as such, and was limited to sRGB ... I know I'm using "managed" in both this technical sense and for the feature, which can be confusing).

*nods*

 

 

The topic of how to expose the color spaces had quite a bit of discussion in WhatWG and landed on using an enum, so the IDL will throw if an invalid enum value is used.

I think that answers my next question - how can we do the same for future color spaces? IIUC, you're saying that this would be addressed by catching such exceptions.

Yes, this was something that we discussed in the WhatWG review in some depth (it was something that the ColorWeb proposal left as "defer to WhatWG"). The menu of options were: (1) use an enum and have an interface to query the presence or absence of values (2) use a string and have some default behavior for invalid values and (3) use an enum and throw in unrecognized values. We landed firmly on (3), but we did explore the first two (and variations thereof) quite thoroughly.

That sounds reasonable as long as it's well-documented (to avoid future value additions resulting in breakage in untested and non-supporting browsers). May make sense to encourage a try..catch pattern even today, to reduce developer cognitive load later on.

[Christopher Cameron]

That's what I'm cleaning up.

[Christopher Cameron]

Yes. Maybe a simpler "demo" of this situation is:

• A <canvas> next to <img>
• The source of the <img> is a P3 image
• The source of <img> is also drawn into <canvas> (I'll just say with no modifications, for simplicity)
• Are the <canvas> and the <img> identical?

Indeed, the "clamping to sRGB" will be exactly what happens to the right side of the screen in that demo. It will be a noticeable change on a non-sRGB display.

 

Assuming it is, if the canvas is color managed (let's say, in Chromium once you've shipped this), I can load those 2 images as P3 ones.

If the canvas is not color managed at all (e.g. on an old version of Chromium), then the one drawn to canvas would be converted to sRGB, resulting in clamping. If so, I probably want to load the 2 images as sRGB.

For me to do that, I need to be able to feature-detect whether the canvas is color managed or not. How can I do that?

This can be done by querying the CanvasRenderingContext2DSettings and seeing if there exists a colorSpace member (if not, then the feature is absent). I have a worked example here (it is written against an older version of the proposal from last year, which had a bunch of other features).

(Slight terminology nit -- 2D canvas has been color managed for a couple of years, it just hasn't been documented as such, and was limited to sRGB ... I know I'm using "managed" in both this technical sense and for the feature, which can be confusing).

 

The topic of how to expose the color spaces had quite a bit of discussion in WhatWG and landed on using an enum, so the IDL will throw if an invalid enum value is used.

I think that answers my next question - how can we do the same for future color spaces? IIUC, you're saying that this would be addressed by catching such exceptions.

Yes, this was something that we discussed in the WhatWG review in some depth (it was something that the ColorWeb proposal left as "defer to WhatWG"). The menu of options were: (1) use an enum and have an interface to query the presence or absence of values (2) use a string and have some default behavior for invalid values and (3) use an enum and throw in unrecognized values. We landed firmly on (3), but we did explore the first two (and variations thereof) quite thoroughly.

 

 

On the code front, it seems like "colorSpace" is not behind the CanvasColorManagement flag. Is there a different flag that makes sure it's not already web exposed?

[Christopher Cameron]

On Wed, Jun 9, 2021 at 12:23 AM Yoav Weiss <yoav...@chromium.org> wrote:

To clarify about matching -- because the 2D canvas is managed, images and CSS colors will always match (up to to clamping) in a P3 space versus a sRGB space -- there is no way to specify "raw" pixel values.

The topic of how to expose the color spaces had quite a bit of discussion in WhatWG and landed on using an enum, so the IDL will throw if an invalid enum value is used.

 

On the code front, it seems like "colorSpace" is not behind the CanvasColorManagement flag. Is there a different flag that makes sure it's not already web exposed?

Sorry, there was some confusion there, I'm cleaning it up (CanvasColorManagement covered a number of features, and I moved the "stuff from the OT that was cut"  behind the flag).

 

[Yoav Weiss]

LGTM1

Seems like the TAG review went well, which gives us further confidence in the design. Thanks for bearing up with all my questions! :)

Contact emails

ccam...@google.com, yiyix@google.com, fs...@google.com, ju...@google.com

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

[Chris Harrelson]

LGTM2

Contact emails

ccam...@google.com, yi...@google.com, fs...@google.com, ju...@google.com

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

[Daniel Bratell]

LGTM3

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8p8uY%2BLvhswhC2_JLMdB4_agjzCm7eWbbcyCCqdqa-ew%40mail.gmail.com.

[Christopher Cameron]

Thanks everyone for the feedback throughout this!