Hello TAG,

On 19 Feb 2024 in Tokyo there is a cross-SDO meeting HDR Stills Experts Day, with the International Color Consortium, W3C, and ISO TC 42/WG 23 (Photography) on the subject of HDR imagery. It would be super-useful to get any TAG input from this HDR in Canvas review ahead of that meeting

@svgeesus Where is the meeting announced in the context of W3C? Any requirements for participation?

@palemieux It is on the ICC site in the Member-only area. It isn't a public meeting. I will be there, and Chris Cameron also.

What is the process if myself and other W3C members wish to attend?

To be clear, my concern is with the output of the meeting being described as including an opinion from the W3C and/or input provided in the meeting be presented as W3C input, without such input having been discussed/reviewed by W3C participants.

I think the proposed modification to the Web Platform to support High Dynamic Range (HDR) imagery in HTML Canvas has been adequately discussed that it can be presented at the meeting, no?

Ok. Which document(s) are you planning on presenting -- beyond https://github.com/w3c/ColorWeb-CG/blob/hdr_canvas_r2/hdr_html_canvas_element.md? It would be good to inform their respective groups.

This doesn't seem like the right repository for this side discussion.

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?

@ palemieux this issue is waiting for a response from ColorWeb CG and/or the proposers, regarding the questions from the TAG review

While we appreciated the discussion on volume mapping, we still had questions about the specifics.

@LeaVerou To make sure we address the question correctly, can you specify what is missing in Annex A?

The part of the API around checking whether a color is in within the volume of the output device

@LeaVerou Do you mean this part of the API.

If so, how is it too close to the hardware? Note the API does not require the returned values to match the hardware exactly, and may reflect user preferences/OS limitations/environmental conditions/etc.

That part of the API is intended for advanced applications. The vast majority of applications are expected to merely set the Canvas to an HDR colorspace and write pixels in that colorspace, letting the UA/OS/Device render the HDR pixels as appropriate based on current conditions.

FYI. Comments above have been entered at https://github.com/w3c/ColorWeb-CG/issues?q=is%3Aopen+is%3Aissue+label%3Atag-comment.