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]

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