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.
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.
Contact emails
ccam...@google.com, yi...@google.com, fs...@google.com, ju...@google.comExplainer
https://github.com/WICG/canvas-color-space/blob/master/CanvasColorSpaceProposal.mdSpecification
https://github.com/whatwg/html/pull/6562 (already merged)API spec
YesSummary
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
BlinkSearch tags
canvas, display-p3, color spaceTAG review
None. This spec was developed and discussed at great length in the W3C's ColorWeb CG.
TAG review status
Not applicableRisks
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?
YesFlag name
CanvasColorManagementTracking bug
https://crbug.com/1083693Link to entry on the Chrome Platform Status
https://www.chromestatus.com/feature/5807007661555712Links 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.
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.comExplainer
https://github.com/WICG/canvas-color-space/blob/master/CanvasColorSpaceProposal.mdSpecification
https://github.com/whatwg/html/pull/6562 (already merged)API spec
YesSummary
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
BlinkSearch tags
canvas, display-p3, color spaceTAG 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 applicableRisks
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 signalsHave 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).
TAG review status
Not applicableRisks
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.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 signalsHave 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).--Is this feature fully tested by web-platform-tests?
YesFlag name
CanvasColorManagementTracking bug
https://crbug.com/1083693Link to entry on the Chrome Platform Status
https://www.chromestatus.com/feature/5807007661555712Links 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.
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.comExplainer
https://github.com/WICG/canvas-color-space/blob/master/CanvasColorSpaceProposal.mdSpecification
https://github.com/whatwg/html/pull/6562 (already merged)API spec
YesSummary
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
BlinkSearch tags
canvas, display-p3, color spaceTAG 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 applicableRisks
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 signalsHave 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?
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.
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).
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).
Yes. Maybe a simpler "demo" of this situation is: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.
- 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?
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.
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?
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?
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
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.