Re: [w3ctag/design-reviews] Canvas 2D color management (#646)

Hi @ccameron-chromium!

Fantastic to see a proposal to color manage Canvas, and extend it beyond sRGB. 👍🏼 
It's unfortunate that sRGB has to be the default, but completely understandable for web compat.

Here are some questions that occurred to me on initial reading.

- You say the target is Chrome 92. However to my knowledge, there are no plans to implement `color(display-p3)` or `lab()` or `lch()` in Chrome 92. Without those, it would be impossible to *draw* graphics that utilize P3 colors, and thus the only value-add of this implementation would be the ability to paint P3 images on canvas. Is that the case? Does Chromium plan to implement `color(display-p3)` but only for Canvas? Something else?
- I imagine eventually we'd want to extend this to the Paint API’s [`PaintRenderingContext2D`](https://drafts.css-houdini.org/css-paint-api-1/#2d-rendering-context). Given that the context for that is pre-generated, how would that look like?
- Is this intended to become 10 bit by default [once 10 bits per component](https://github.com/w3c/ColorWeb-CG/blob/master/hdr_html_canvas_element.md#higher-bit-storage-formats-for-2d-contexts) are supported? Could this introduce web compat problems?
- <blockquote>Input colors (e.g, fillStyle and strokeStyle) follow the same interpretation as CSS color literals, regardless of the canvas color space.</blockquote> What happens when someone paints an e.g. <code>rec2020</code> color on an sRGB or Display P3 canvas? Is the result gamut mapped? If so, how?
- If I understand the explainer correctly, this means that the first script that calls `getContext()` gets to define the color space the canvas is in. What happens on any subsequent `getContext()` calls, either without a colorSpace argument, or with a different one? Do they produce an error or silently return the existing context, color managed with a different color space than the one the author specified? Do they clear the contents? Not sure any of these options is better than making `colorSpace` be mutable (which would also address `PaintRenderingContext2D`). It is not that unheard of to change the color space of color managed graphics contexts, e.g. it's possible in every color managed graphics application I know of, and there are several reasonable ways to do it.
- Am I reading it correctly that `getImageData()` will return sRGB data even in a P3 canvas, unless P3 data is explicitly requested? What's the rationale for not defaulting to the current color space?
- <blockquote>The color space is then an immutable property of the CanvasRenderingContext2D.</blockquote> Unless I missed it, none of your Web IDL snippets include this readonly attribute. I assume in unsupported color spaces this attribute will be <code>"srgb"</code>?


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/646#issuecomment-858930293