Re: [w3ctag/design-reviews] Adding support for High Dynamic Range (HDR) imagery to HTML Canvas (Issue #917)

Hi there,

@plinss @ylafon and I looked at this today during a breakout.
We had a few thoughts and questions:

1. The part of the API around checking whether a color is in within the volume of the output device and mapping it manually by the author seemed both too close to the hardware to be future-compatible, and too low level to have good DX. We think a higher level method to check whether a color is within the range of the output device would be preferable. 
2. The Canvas APIs do not seem like the right place to specify primitives for querying the volume of the output device, which are useful in APIs across the entire web platform. 
3. While we appreciated the discussion on volume mapping, we still had questions about the specifics. We see several cases where gamut/volume/tone mapping come into play, and we’d love some more detail on how these are handled (actually, the same questions apply to wider/smaller gamuts too):
 1. HDR image painted on a non-HDR canvas
 2. HDR canvas displayed non-HDR screen
 3. Author painting an HDR CSS color on a non-HDR canvas
4. The used color space is a property of CanvasRenderingContext2D, but HTMLCanvasElement provides methods for *exporting* the canvas contents as an image (`toBlob()`, `toDataURL()`). Is the color space preserved during these operations? (again this also applies to wide gamut)

And some more minor comments:
- Since CSS Color HDR has been approved as a workstream by the CSS WG, this work should probably reference it in the same way it references css-color-4.
- `screen.screenColorInfo` seems a little repetitive, why not `screen.colorInfo`?

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

Message ID: <w3ctag/design-reviews/issues/917/1964765613@github.com>