W3C home > Mailing lists > Public > www-style@w3.org > June 2012

Re: [css4-color] Make the r/g/b components be <number> rather than <integer>?

From: Witold Baryluk <baryluk@smp.if.uj.edu.pl>
Date: Sun, 10 Jun 2012 01:13:55 +0200
To: Rik Cabanier <cabanier@gmail.com>
Cc: "L. David Baron" <dbaron@dbaron.org>, Simon Sapin <simon.sapin@kozea.fr>, www-style@w3.org
Message-ID: <20120609231355.GT5511@smp.if.uj.edu.pl>
On 06-09 23:01, Rik Cabanier wrote:
> On Sat, Jun 9, 2012 at 12:54 AM, L. David Baron <dbaron@dbaron.org> wrote:
> > On Saturday 2012-06-09 00:42 +0200, Simon Sapin wrote:
> > > Le 08/06/2012 22:20, Tab Atkins Jr. a écrit :
> > > >Could we make the rgb components of rgb/a() be <number> rather than
> > > ><integer> in level 4?
> > >
> > > I’m in favor; I don’t see a downside in allowing it.
> > >
> > >
> > > >I suggest we cast the components to integers in the same way we did
> > > >for Transitions - normal round, .5 goes toward positive infinity.
> > >
> > > I’m not sure what rounding this is. I understand that as "n + 0.5 is
> > > rounded to n + 1" (with n an integer). What about n + 0.1 ? In the
> > > current Transitions ED I read "The interpolation happens in real
> > > number space and is converted to an integer using floor().", I think
> > > so n+0.5 would be rounded to n, not n+1
> > >
> > > In any case, the spec should define how to round (in what
> > > direction), but maybe not at which resolution. If an implementation
> > > can support more than 8bits per color channel the spec’ed rounding
> > > should not limit that.
> >
> > So I think any definition of rounding behavior should be general to
> > colors, not specific to rgb(<integer>, <integer>, <integer>).  We
> > already allow arbitrary precision colors with rgb(<percent>,
> > <percent>, <percent>).
> >
> > I'd be inclined to say there might be advantages to not defining
> > rounding behavior here.  The experience I've seen with color
> > management on different platforms has been that they round
> > differently, but being off by one color component doesn't sound all
> > that serious.  Being able to benefit from hardware acceleration may
> > outweigh being able to define every result exactly.
> >
> >
> I agree. If the hardware supports more than 8bpp or if there's color
> management, it's better that floating point is preserved.
> Rik

I think my propositions from few months ago about linear RGB support
should be considered here.

sRGB is doesn't much sense for negative values of compontents, due way
it is convereted. Also in case compontents are implemented as floating
point values or 16bpc (bits per color compontent) or more, there is no
big need for gamma correction (which is just a compression of color
value based on  human perception of colors intensity). I know sRGB is
slightly modified version of gamma correction, and it may be possible to
extend it to negative values, but nobody defined such extension. Linear
RGB however have quite clear minning.

In case of linear RGB (which in fact should be used always after sRGB is
converted to it), with compontents represented as numbers (i.e. floats
which in fact are hardware accelerated on most hardware using, for example using _SRGB OpenGL
extensions which converts from/to sRGB to real linear RGB from supplied
sRGB source textures or sRGB framebuffer or target texture).

Also sRGB is not suited for any kind of mathematical operations (like
mixing two colors compontent by component!). It is only suitable to:
storage or transmission without change, direct display on sRGB
compatible medium or proper conversion to other color space (like linear
RGB, which can be used directly in mathematical operations). The fact
that current User-Agents operates on sRGB when doing things like
css-transistions on color/background-color, color linear/cicular
gradients or alpha blending of transluent layers is very unfortunete and
inccorrect usage of sRGB, which proofs original authors of specification
didn't know what sRGB is for and what not for. Different aspect is that
most of User-Agents if not all, incorrectly handles scalling of sRGB
<img> sources, performing for example bilinear of bicubic interpolation
on sRGB colors! (it should be first converted to linear space before
that). In current days where sRGB is hardware accelerated, and in fact
can be done with small lookup table even on CPU, I do not see much
performance benefit with ignoring it and implementing incorrectly.

As of rounding behaviour, I think color should be preserved as was. It
allows displays which have wider or better color space (like 10bpc LCD
displays, or good print). Also by not exactly defining it, it can be
hardware accelerated in straight forward manner. I think if anybody
writes such strange values to CSS style sheet, he/she should know what
he is doing and intepreted as closly as possibly to this style.

As of the problem of being "off by one", is VERY serious in sRGB color
space, and even in linear space can be important. Just draw yourself a
gradient across a screen from #000 to #cc0 (assuming sRGB), and you will
clearly see a bands! Error by one will make this bands considerably
different and easly noticable. Human eye see much more than sRGB can
provide in 24bpp.


Witold Baryluk
Received on Saturday, 9 June 2012 23:14:25 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:00 UTC