Re: [css-color] wider/deeper colors

Hi Chris,

> On 2 Feb 2016, at 00:27, Chris Lilley <chris@w3.org> wrote:
> 
> Sunday, January 31, 2016, 9:52:38 PM, you wrote:
> 
>> In preparation for discussion of this topic at the face-to-face
>> meeting, a summary of where (I think) we are on this topic:
> 
> I will try to join this discussion by phone.

Unfortunately it happened the day before you sent this message.
Your expertise was missed!

The TLDR is that we're waiting on you to make a more
detailed proposal, but I might make one in the meantime
(which I would expect you to tear apart and improve).

> 
>> 0. Firstly, not much has changed since my last email thread on this
>> topic, which has some good discussion [1].
> 
> 
>> 1. The specification already allows values outside of [0,1] inside
>> the rgb() function, although no-one implements it yet.
> 
> Correct. they don't do for several reasons; a major one is because the
> transfer curve is non-linear and thus is only defined inside [0,1].
> There are some plausible ways to extend it below zero (continue the
> linear portion is one; mirror the transfer curve about zero is
> another). It is even worse for values greater than 1, as the curve is
> already fairly flat so you have to extend a lot to get any actual
> increase. xvYCC defines another way to do this.
> 
> A second one is that many color management systems, until recently,
> did early clamping because hey could not handle values outside [0,1]
> anyway.
> 
> A third reason is that, while it is theoretically true that values
> outside of [0,1] can be used to describe any out of gamut color, in
> practice such colors are specified in Lab.

We asked Adobe for some feedback on how they expect the workflow
for these situations to go. How will authors pick colors? How will
the colors in the authoring tool be exported to a syntax that
CSS can accept?

It's not (yet) clear if authoring such values by hand will make any
sense. If you consider the r, g and b inputs as infinite axes, then
I guess you can imagine someone wanting "more red" and bumping
past 100%. However, the result isn't really that simple.

Anyway, more descriptions of color workflows, in any use case,
would be appreciated.

> 
>> However, we
>> don't describe what such values actually mean. I think we should
>> investigate describing them as using the scRGB space [2].
> 
> scRGB is a good choice because it has a linear transfer function.
> 
> The video industry has instead chosen xvYCC
> https://en.wikipedia.org/wiki/XvYCC
> because conversion to sRGB gamut can be done by simple clamping, and
> because it is compatible with JPEG (and other MPEG) YCC systems.
> 
>> 2. We will add a new function for describing colors that accepts a
>> color-profile name and a variable number of arguments. e.g.
>> color("bt2020", 0.7, 0.3, 0.1). The name can be linked to a
>> @color-profile, but we will also have some predefined keywords for
>> the most common profiles.
> 
> Yes, exactly. I was thinking of icc rather than color, which is
> shorter and more descriptive (these are icc profiles).

That sounds fine by me.

> 
> SVG used icc-color which is a bit long. It also required an sRGB
> fallback everytime, which on reflection is not actually needed (if the
> implementation is icc-unaware, the user can provide a fallback in the
> usual CSS way; if it is icc-aware, then it can produce an Lab or XYZ
> or sRGB value for those situations where one is needed).
> 
>> 2.a (alternate) Similar to 2 but just add a function that accepts
>> BT.2020 because "640kb ought to be enough for anybody".
> 
> Less extensible than the first option and not really worth it;
> increases spec pressure to add new values; prevents using color
> managed cmyk or hexachrome profiles.

Yes, this wasn't something we were pushing for, unless the
main option was going to be too complicated to make happen in
a reasonable time.

> 
>> 3. Add a media query to enable detection of a hardware and software
>> stack that will process colors outside of sRGB.
> 
> Yes. I hope we have some good discussion on this one. Would this go
> into MQ4 or color-4?

I don't know.

> 
>> This could take the
>> form of "awesome-colors: none | some | plenty" which map to what
>> most people have today, something about DCI P3, and then something
>> about BT.2020 (i.e intentionally slightly vague), or something that
>> allows detection of a named profile.
> 
> A bit wooly :)
> 
> There are two somewhat independent capabilities to be queried here,
> bit depth (also called deep color by the video industry) and extended
> gamut. I say somewhat independent because you typically need them
> both, to avoid banding.
> 
> The third capability is icc-awareness, which in practice has three
> values (none, v2, v4).
> (Yes, there is no v1 or v3 of ICC :)

Right. Apple ships hardware with extended gamut. Simon may
correct me, but I don't think we ship any Web-facing features (yet)
that have a greater bit depth.

While we could come up with media queries that detect all
these things individually (extended gamut accepted as input,
extended gamut supported on output, greater bit depth as input,
greater bit depth preserved on output, number of bits per
channel, etc), I think a more simple media query works in the
majority of cases: developers just want to know if the hardware
and software stack on the user's computer supports "better"
colours than today's typical hardware.

Noel from Google (who might be reading this) expressed it
pretty well to me in person today: I'm selling red shoes. What do
I do to get a photo on my web page that most accurately
shows the shoes to the customer?

Obviously a lot depends on the quality of the display and
especially the viewing environment, but maybe just knowing
there is a good/better/best display on the other end, along
with a browser that will take advantage of it, is a good
start.

> 
>> 3.a (alternate) Florian suggested something more like @supports,
>> where you give something from points 1 or 2 above, and the system
>> will tell you if it could handle it. I like this idea, but we'd need
>> to be careful to describe what it means to handle the color.
> 
> That seems odd; for an icc-aware system it is asking if it could
> handle a given icc profile. Except for v.2 implementation vs v.4
> profile issues, the answer is always "yes".

I think the intent was "will this color be accurately displayed
or will it be clipped/mapped/munged"?

Dean

Received on Wednesday, 3 February 2016 09:52:38 UTC