- From: Chris Lilley <chris@w3.org>
- Date: Mon, 1 Feb 2016 15:27:45 +0200
- 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