Re: [css-color] wider/deeper colors

> On Nov 2, 2015, at 4:57 PM, Florian Rivoal <florian@rivoal.net> wrote:
> 
> 
>> On 03 Nov 2015, at 08:09, Dean Jackson <dino@apple.com> wrote:
>> 
>> Hi,
>> 
>> We had a productive discussion about colors outside sRGB last week and I wanted to summarize the outcome. I also have provided some new comments. Please let me know if I got details incorrect. And please remember, IANACE (color expert).
>> 
>> 1. Add a new media query that is able to detect the "depth" of the display. I put that word in quotes because I think the current "color" query isn't sufficient and we need a term to better describe what we're trying to detect. The "color" query examines the number of bits per channel, but that doesn't allow you to ask if the display can show things outside sRGB. Instead we suggest there should be range-type query that allows you to detect "normal" (typical displays from today, in the sRGB range or about), "extended" (wider gamut displays, in the DCI P3 range or about) and "super-awesome-needs-a-better-name" displays (very wide gamut displays, in the Rec. 2020 range or about). I believe this might be the first media query that has named values but works as a range. We don't have good suggestions for the name of this query.
> 
> Note sure this has to be a range query. If you go with "awesome-colors: none | some | plenty", you can do "@media (awesome-colors) {...}" and have it match whenever the value is something other than none. Wouldn't that be enough?

Yeah, that should work. We just need to think of names.

> 
> Also, while I agree we should have a media query on this topic, is this the right way to slice the problem?
> Maybe we should parallel the approach suggested for round display, and let you specify a color (in CIE-Lab) or a color space profile, and have the media query tell you whether or not the display can handle it.

But what does "handle" mean? A display can handle anything really. If you're asking "does this display completely cover the gamut available to this profile?" then the answer might be yes, but it might be "close enough". And then people would need to know what profile to ask for.

In your case you're asking if a particular color is handled, but that's pretty much the same question. We'd need to ask how far off the requested color the final color is. And I expect different displays have slightly different supported profiles. 

I think we can really only talk in generalities. That's why I said "sRGB range or about", "P3 range or about", etc. Basically ok, good, better, betterer, etc. This might be a mistake, but I don't think we can be more specific.

> 
> 
>> 2. The specification already says that values outside the sRGB space are supported. We're thinking of turning this on in WebKit soonish, but have some fears that there is content out there that might change as a result. You could argue that such declarations are probably an error, but you never know. It's also not yet clear how an author will calculate these values, considering popular imaging software doesn't provide them (e.g. photoshop clamps the RGB values and gives you a warning).
> 
> Also, if you're specifying values outside of the color space used by the display (sRGB), don't you need to chose on a rendering intent to have any idea what these are supposed to be displayed as?

This is a good question. I assumed that the transfer function for sRGB would allow values outside the range to convert into something meaningful. I'm not sure if that is correct.

> 
>> 3. We suggested adding a form of the rgb() function that takes a fourth parameter that names a colorspace. The name might come from an @color-profile rule, and we might have some hard-coded names. FWIW, we think that we should wait to see if Comment 2 works in practice before adding new syntax. And we'd need to decide what hard-coded profiles are useful ("AdobeRGB" was mentioned, although that seems to be designed for CYMK workflows - DCI P3 could be more appropriate).
> 
> We also said that having this "fourth" parameter be the first one would make things more flexible, allowing color space with 3 parameters (rgb), 4 parameters (cmyk), or even a single parameter (pantone, or other named colors).

I remember this discussion, but shouldn't this be a new function - such as defined-color(profile, params...). The rgb function clearly takes three value parameters.

Dean

Received on Tuesday, 3 November 2015 01:16:51 UTC