Intent to Ship: Canvas Color Management

[Mohammad Reza Zakerinasab]

Contact emails

fs...@chromium.org, zaker...@chromium.org

Spec

The spec update is in progress. We intend to ship half float canvas pixel format and allow creation of contexts with extended sRGB color space. Non-sRGB color spaces (linear-rgb, p3, rec2020) still remain behind the flag.

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

MVP launch document: https://docs.google.com/document/d/1WsKDjAl6oOkiacSh94Mh5XVgb_SefwFbIZO5KXuYz5o

Summary

The new “float16” pixel format for canvas, along with other extensions in ImageData and ImageBitmap API, make it feasible to use HTMLCanvasElement for displaying and manipulating wide color gamut content. When the canvas pixel format is set to float16, each color component / alpha channel can store and represent up to 16 bits of data, which is enough for the current trend of 10 bit wide color gamut content. Furthermore, the color gamut is extended-sRGB, which virtually covers all the traditional wide gamut color spaces, including P3 and Rec2020. Hence, color precision is preserved when dealing with wide gamut content.

Furthermore, new API for ImageData allows to read back the pixels from half float backed canvas as a Float32Array, manipulate them as necessary, and put them back on canvas without any color precision loss. This can be a  perfect tool for wide gamut content editing on web. Similarly, the extended API for ImageBitmap allows to store, upload, and transfer wide gamut content without any color precision loss.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/%22color$20management%22%7Csort:date/blink-dev/qu73qpdGunE/FoOgPZ6-FAAJ

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

Yes.

Debuggability

This feature does not require special debugging support on its own.

Interoperability and Compatibility Risk

Interoperability risk is medium. There is no support for this extended API from other vendors right now, but we hope them to get this implemented when it is landed in the spec.

Compatibility risk is low, as this does not remove or change existing features.

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

Yes.

OWP launch tracking bug

crbug.com/634542

Entry on the feature dashboard

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

[Yoav Weiss]

Thanks for working on this! Seems like a needed feature for color-accurate image manipulation on the web.

OTOH, the intent doesn't quite match the template, and missing TAG review and ergonomics section. 

On Thu, Oct 25, 2018 at 7:30 PM 'Mohammad Reza Zakerinasab' via blink-dev <blin...@chromium.org> wrote:

Contact emails

fs...@chromium.org, zaker...@chromium.org

Spec

The spec update is in progress. We intend to ship half float canvas pixel format and allow creation of contexts with extended sRGB color space. Non-sRGB color spaces (linear-rgb, p3, rec2020) still remain behind the flag.

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

MVP launch document: https://docs.google.com/document/d/1WsKDjAl6oOkiacSh94Mh5XVgb_SefwFbIZO5KXuYz5o

Summary

The new “float16” pixel format for canvas, along with other extensions in ImageData and ImageBitmap API, make it feasible to use HTMLCanvasElement for displaying and manipulating wide color gamut content. When the canvas pixel format is set to float16, each color component / alpha channel can store and represent up to 16 bits of data, which is enough for the current trend of 10 bit wide color gamut content. Furthermore, the color gamut is extended-sRGB, which virtually covers all the traditional wide gamut color spaces, including P3 and Rec2020. Hence, color precision is preserved when dealing with wide gamut content. 

Furthermore, new API for ImageData allows to read back the pixels from half float backed canvas as a Float32Array, manipulate them as necessary, and put them back on canvas without any color precision loss. This can be a  perfect tool for wide gamut content editing on web. Similarly, the extended API for ImageBitmap allows to store, upload, and transfer wide gamut content without any color precision loss.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/%22color$20management%22%7Csort:date/blink-dev/qu73qpdGunE/FoOgPZ6-FAAJ

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

Yes.

Debuggability

This feature does not require special debugging support on its own.

Interoperability and Compatibility Risk

Interoperability risk is medium. There is no support for this extended API from other vendors right now, but we hope them to get this implemented when it is landed in the spec.

 

Have you reached out to other vendors? Opened issues?

Compatibility risk is low, as this does not remove or change existing features.

Thanks for including feature detection description in the explainer! Would be great if you could also add a short code example on that front.

Also, what would be the future compat story if we'd want to add more colorspaces in the future? Will developers be able to query the supported colorspaces, or have to feature detect them one by one? (this is potentially something we can think of later, but wondering if it was discussed)

 

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

Yes.

Can you link to the test suite?

 

OWP launch tracking bug

crbug.com/634542

Entry on the feature dashboard

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

--
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/CAJ%2BVBmzovO-k1mKNXdn4_FiPWZz8O%3DUyjFjsq3CQZ_LRU%3DD2DQ%40mail.gmail.com.

[Philip Jägenstedt]

Hi Mohammad, Fernando,

May I ask about the plan to either upstream https://github.com/WICG/canvas-color-space/blob/master/CanvasColorSpaceProposal.md into HTML or to publish it as its own spec? Shipping a new feature typically requires a slightly more formal spec, with enough details for other vendors to be able to implement.

On web-platform-tests, can you list the relevant tests? I did some quick grepping but am not sure which they are.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgKz8z_oVkWqkHSOMvnV3XPB5QkPTA%3DcZSpYS-UcEeLWQ%40mail.gmail.com.

[Fernando Serboncini]

We do have 2 specs changes in flight at WHATWG:

https://github.com/whatwg/html/pull/3926

https://github.com/whatwg/html/pull/3882

and two more waiting after those 2 land.

For the WPT tests, I think they are in 2dcontext/wide-gamut-canvas/ for now.

[Philip Jägenstedt]

Thanks!

I've commented on both of those PRs, hopefully we can move them along.
For the remaining two, although GitHub doesn't properly support
dependent PRs, do you think it'd be helpful to send PRs building on
the previous ones?

Is it OK to consider this intent blocked on landing the spec and test changes?

[Fernando Serboncini]

Update on this.

We have a "generic" issue discussion on WhatWG: 

https://github.com/whatwg/html/issues/4167

that describes the IDL changes we are proposing. 

(this is a sum of all smaller whatwg spec changes we are submitting).

On this, we got a clear support from Safari. And addressed most issues presented by Firefox. There's still some minor debates, but the overall face of the API seem to be agreed upon.

The parallel discussion on W3C is:https://github.com/w3ctag/design-reviews/issues/315

Here, we also answered most of the questions presented, mostly around defining extended sRGB.

I'd suggest that this should unblock this Intent to Ship as far as "Spec changes" go, since we have a good buy in on both forums, even though there's still some work to do on wording those changes on the spec.

[andreas...@gmail.com]

Good to see progress in this area. A lot of applications would benefit from proper color management in Canvas/WebGL, e.g. image editing software and medical imaging applications.

Before this is implemented, what color space is assumed for Canvas, or the WebGL draw buffer? To be precise, in the latter case, in what color space should one assigned colors to gl_FragColor?

Is the current state that it isn't possible to do color correct rendering on a wide gamut display in WebGL on Chromium?

BTW, is there any prognosis on when this might be implemented? I have seen mentions that this is already implemented as an experimental feature, but there doesn't seem to be a flag for it.

[Philip Jägenstedt]

Hi Fernando,

Great to hear that the design is moving forward and approaching consensus. Are these still the only two spec PRs involved?

https://github.com/whatwg/html/pull/3926

https://github.com/whatwg/html/pull/3882

Normally both spec and test changes are merged by the time we ship something, so that other implementers need not poke us to finish it if it drags out. A minor perk of this is also the ability to see the test results at https://staging.wpt.fyi/results/ for things that are behind --enable-experimental-web-platform-features, which CanvasColorManagement is.

Sometimes the order has been flipped and that can be fine, I'd just like to understand if there are particular reasons for it?

P.S. This ordering doesn't mean that all spec editors and other vendors have an effective veto in our launch process. If something gets stuck in the standards process and we're still convinced that it's a good idea, we can still do it by publishing it as a standalone spec or a spec fork. That sounds dramatic and I'm not suggesting it's relevant in this case, just that the obvious flaw with "block shipping on spec changes" isn't quite so bad.

[Daniel Bratell]

It looks like one of them is ready for integration into the specification. Not sure about the other?

fserb, what is your position right now? We (API owners) have this as waiting for progress on the spec side and it's been a while since the last update.

/Daniel

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

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Yoav Weiss]

Friendly post-holidays ping :) Any updates on the spec side of things?