W3C home > Mailing lists > Public > www-style@w3.org > February 2016

Re: [css-color] wider/deeper colors

From: Chris Lilley <chris@w3.org>
Date: Mon, 1 Feb 2016 15:27:45 +0200
Message-ID: <1212520855.20160201152745@w3.org>
To: Dean Jackson <dino@apple.com>, www-style list <www-style@w3.org>
Hello Dean,

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.

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

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

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.

> 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?

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

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


-- 
Best regards,
 Chris  Lilley
 Technical Director, W3C Interaction Domain
Received on Monday, 1 February 2016 13:27:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:00 UTC