Re: [css-color] wider/deeper colors

On Mon, 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?
>
> 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.
>
>
> > 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?
>

I was told by our color guys, that 1D simple profiles such as sRGB and
AdobeRGB don't support rendering intent so it's always a colorimetric
conversion.
At least for Adobe's CMM, you can only do overshooting of the color range
for 1D color spaces. If the source or destination profile is a 3D/4D space,
the values will be clipped before mapping the gamut.
Almost all RGB profiles are of the simple type with the exception of high
end monitors or those that used a optical tool to calibrate them.

I'm unsure if other CMMs support this and can't find any information
online. It's very likely that most of them clip which would slow down the
implementation.


> > 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).
>

Some of Adobe's users like to work with color management turned off. Maybe
we can do the same and support an "uncalibrated" profile that simply puts
the values to the screen.

Using named profiles seems like a much more elegant and less error prone
solution...