Re: Chrome, re: Color on the Web TPAC

Thanks Chris for facilitating and consolidating these responses! Some 
very interesting answers in there.

On 2019-11-02 03:37, Chris Cunningham 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
> *
> *

-- 
Chris Lilley
@svgeesus
Technical Director @ W3C
W3C Strategy Team, Core Web Design
W3C Architecture & Technology Team, Core Web & Media