Re: Chrome, re: Color on the Web TPAC

Adding some googlers to CC

On Fri, Nov 1, 2019, 6:37 PM Chris Cunningham <chcunningham@google.com>
wrote:

> Hey Group,
>
> I sat in on this meeting
> <https://www.w3.org/2019/09/17-colorweb-minutes.html> and committed to
> get some answers from Chrome color folks.
>
> Apologies for the delay! I made the mistake of starting an internal thread
> with the intention of writing a summary to the color group. But that thread
> got crazy long with internal details and tangents and its very difficult to
> distill. I'll instead give simple incomplete answers and I expect
> my @google colleagues to fill in the gaps and answer follow ups :). Next
> time I'll just start the thread here...
>
>
> *1. How do we feel about controlling HDR at element level vs the page
> level? Folks made the point that it seems desirable to do element level to
> enable mixing content, but Apple compositing dev was worried this would be
> difficult for implementers.*
>
> We generally support doing this at the element level. There are plenty of
> challenges with both approaches. Per-element seems the most conceptually
> clean. For ex, if you specify that the page is HDR, what does it then mean
> when you load a non-HDR image? Pages cannot avoid this - they may not have
> total control over the content they load or what context (top frame vs
> iframe) they were loaded in.
>
> Pages need some way to know when HDR is supported (and perhaps when/if
> that changes dynamically). On that note, see CSS discussion here:
> https://github.com/w3c/csswg-drafts/issues/4471
>
> * 2. As a UA, what is our level of interest in HDR color throughout the
> stack? Are we only interested in video? canvas? gl? or do we support hdr in
> all the things (including css)? The underlying concern: they want to avoid
> spec'ing something that never gets implemented.*
>
> We're interested in HDR throughout the DOM. Obviously video HDR is here.
> Image HDR seems near term. A simple WebGL/Canvas color space proposal has
> been made (implemented in chrome behind flag). And we're watching the CSS
> color spec.
>
> There is some concern (ccameron@) about aspects of the CSS color 4 spec
> (largely about complexity). I expect he'll have some bugs/ emails on that
> shortly.
>
>
> *We also discussed "working color space" intermixed with discussion of
> SDR/HDR blending. Some agreement, but some open issues. *
>
> I'll just drop some interesting key quotes...
>
>    - "Extended-sRGB is the best working color space for compatibility
>    reasons. Of note is that Chrome and Safari defy the spec (and will continue
>    to do so) for power reasons (compositing in sRGB would massively-increase
>    power consumption).
>    I think that having a "switch the working color space for the page"
>    flag is going to be very painful, and I don't see what it gets us."
>    - "Working color space is essentially an implementation detail as long
>    as it is specified how blending and compositing works."
>    - "indeed, I've been using "working color space" and "color space for
>    blending operations" interchangeably (which may be confusing some!)."
>    - "Some of the [CSS] ideas (like working in perceptual spaces instead
>    of RGB) seem great..."
>    - "if we use wide intermediate spaces and then leave it to the OS to
>    figure out how to best output that, we're giving it a very hard to solve
>    problem, throwing away some information in doing so, and we'll see wildly
>    different output by platform"
>
>
> Best,
> Chris
>
>