Add extended range

[ccameron-chromium]

Add color metadata to canvas configuration, with the ability to specify an extended range.

Move the clarification of the handling out out-of-range values to the subsection on specific values, and add an example of extended range values.

Fixes #4239

[github-actions]

Previews, as seen when this build job started (7a3b59a):
WebGPU _{webgpu.idl | Explainer | Correspondence Reference}
WGSL _{grammar.js | wgsl.lalr.txt}

[kainino0x]

The worked examples are great. A few small comments (and holding "editor" approval until others have reviewed)

[kainino0x]

Fixes #4239

FYI I added this to the PR summary to link the issue. Is it correct that landing this would fix/close that issue?

[ccameron-chromium]

Fixes #4239

FYI I added this to the PR summary to link the issue. Is it correct that landing this would fix/close that issue?

Yes, thanks!

[ccameron-chromium]

Fixes #4239

FYI I added this to the PR summary to link the issue. Is it correct that landing this would fix/close that issue?

Yes!

[kainino0x]

Friendly review bump @kdashg @mwyrzykowski

[mwyrzykowski]

Friendly review bump @kdashg @mwyrzykowski

Sorry! It looks good, I forgot to click approve 👍

[kainino0x]

@ccameron-chromium let me know that CSS is hotly debating gamut mapping right now, and we may need to be less prescriptive in this spec lest we contradict what CSS eventually does. I've converted this to draft so it can't be landed accidentally.

[ccameron-chromium]

@ccameron-chromium let me know that CSS is hotly debating gamut mapping right now, and we may need to be less prescriptive in this spec lest we contradict what CSS eventually does. I've converted this to draft so it can't be landed accidentally.

We had originally called the modes "default" and "extended", and then made them more descriptive by calling them "clamp-to-standard" and "clamp-to-extended". While this accurately describes the current behavior on all browsers (as did PR 4400), I think we shouldn't be so explicit in the names of the enums.

The core behavior that we want to capture is that

• in the "standard" behavior, no colors in the SDR gamut of the display will be altered, and all colors outside of the SDR gamut will be projected onto the gamut broder
• in the "extended" behavior, the same thing, except for the HDR gamut

I could imagine changing the names to "project-to-standard" and "project-to-extended", or just sticking with "standard" and "extended". The behavior of clamping is a projection (the L-infinity error minimizing one, for what that's worth). If there a preference between these two name schemes?

[kainino0x]

I probably should have put this on the agenda for today's meeting, but didn't think about it. We're probably not having another WG meeting for 3 weeks but that should be OK.

I've put this on the editors' agenda for this coming Monday so we can talk about naming and then try to get reapproval.

proposal became less strict

[kainino0x]

The names and language LGTM, just small comments to label non-normative language as non-normative.

[kainino0x]

@kdashg @mwyrzykowski could you re-review with the loosened wording and new naming?

[Kangz]

GPU Web WG 2024-05-15

• KN: The CSS WG is still discussing whether clamping is required, so this PR loosens the verbiage to be more lenient so it can match what CSS does eventually.
• KN: The two changes are the enums names that say "project" and the text saying it is projected in the color space, but not necessarily by clamping.
• KG: Will review offline.

[kainino0x]

@kdashg review bump!