- From: Christopher Cameron via GitHub <sysbot+gh@w3.org>
- Date: Mon, 29 Nov 2021 21:07:22 +0000
- To: public-fxtf-archive@w3.org
Over in [this issue](https://github.com/w3c/ColorWeb-CG/issues/65), a very similar issue came up, and at least with respect to RGB (ignoring A for the moment), the general idea is that color values shouldn't be clamped, and should be allowed to express colors of any gamut. The compositor will, at the end, clamp the colors to the gamut of the display, and to the SDR range. With respect to HDR, I do feel that the best thing to do is to specify "we will clamp to SDR unless something is explicitly specified using some yet-to-be-defined API". To open the HDR bikeshed doors a bit ... my sense is that we will eventually want to add a spec that allows an individual element to explicitly enable HDR for-just-that-element. When enabling HDR, it can specify what kind of HDR is desired (just-extended-values, or treat-as-HLG, or treat-as-extended-with-metadata-sort-of-like-PQ). [This proposal](https://github.com/w3c/ColorWeb-CG/blob/master/hdr_html_canvas_element.md) discusses adding HDR to canvas elements. This is also similar to specifying a "working interpolation space" for an element. ([This issue](https://github.com/w3c/ColorWeb-CG/issues/64) discusses whether or not that "working pixel buffer space" should be independent of the "HDR type of space for compositing the element" but ... that's a whole nother bike shed). The status of that spec is "we need to write a prototype so people can feel their way around what is best". To return to the issue at hand, saying "clamp to SDR and the device's gamut at the end of the pipeline" is compatible with all of that. -- GitHub Notification of comment by ccameron-chromium Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/446#issuecomment-982023540 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 29 November 2021 21:07:24 UTC