W3C home > Mailing lists > Public > public-fx@w3.org > October to December 2013

Re: [filter-effects] hue-rotate() and saturate() filters

From: Chris Lilley <chris@w3.org>
Date: Mon, 14 Oct 2013 23:55:57 +0200
Message-ID: <48664838.20131014235557@w3.org>
To: Rik Cabanier <cabanier@gmail.com>
CC: Michael Mullany <michael@sencha.com>, "public-fx@w3.org" <public-fx@w3.org>
Hello Rik,

Monday, October 14, 2013, 11:20:59 PM, you wrote:

> On Mon, Oct 14, 2013 at 1:23 PM, Chris Lilley <chris@w3.org> wrote:

>>  Rik, for someone who has implemented a color management engine in a
>>  commercial product you continually surprise me with what you do and
>>  don't know.

> Really? Can you show me a commercial software product that uses this colorspace?
> A Google search reveals 31 webpages of mostly SVG mailing threads.
>   Maybe this is well known in academics?

If you consider the CIE or the ICC to be academics and academia to be
a perjorative term then yes. But no, SVG didn't invent it.

A few seconds googling would take you to, for example
if you really do need to look up the equations.

Bruce Lindbloom is a well respected colour scientist.
>  In 1976 the CIE produced two colourspaces - CIE L*a*b* and CIE L*u*v*.
>  In normal conversation the asterisks are dropped and they are called
>  Lab and Luv respectively.
>  Polar forms of each were also produced, retaining the L axis and
>  transforming a,b (or u,v) into a Hue angle H and a Chroma (similar to
>  saturation) C. Because the two forms both have the same names for the
>  three axes (L, C, H) they are disambiguated by a subscript ab or uv as
>  appropriate - LCHab or LCHuv.

> OK. Why should we push that complexity to the user?

Because 'that complexity' gives them hue angles that aren't all
bunched up, Lightness values that actually tell you what lightness
something is when you look at it, and so on.

> CIELCHab doesn't sound like a different colorspace from Lab; it's
> more like a simple transform (like hsl()/rgb() in CSS)

Yes, as I said above its a rectangular to polar transform, producing a
different colourspace. Just like a simple matrix transform on
linear-light rgb gets you CIE XYZ, a different colourspace.

Unlike the complex equations for HSL though, which involve a set of
comparisons and branches, the equations to go between Lab and LCHab
are simple trig.

C = sqrt(a^2 + b^2)
H = atan2(b/a)

>   Incidentally these polar forms were what inspired Tektronix et al to
>  come up with HSL, HSV and similar polar forms of RGB. Unlike the
>  measurement-based CIE forms, however, HSL and HSV are not perceptually
>  uniform and have some odd behaviour - primary blue (#00F) and secondary
>  yellow (#FF0) have the same lightness in HSL and the same value in
>  HSV. 

 >> However, doing so would require a whole new set of formulas in the
 >> filters specification and a lot of work in the browsers...
>  Not really. In each case, you transform to the working colourspace,
>  perform channelwise operations, then transform back.

> The same channelwise operations? So the sepia, grayscale or
> saturate formulas wouldn't change?
> No, the formulas would have to be different.
Yes, those ones would change. For example in Lab or LCHab the
greyscale formula would be

greyscale = L

and to get a boost to chroma by some factor k, while leaving lightness and hue
unaffected you would do

C *= kC

As to whether implementors would consider this complex, it depends. If
you make it sound terribly scary and complex while at the same time
asserting that its of merely academic interest then sure, they won't
even look into it.

If you make the argument at a technical level though, an identity operation and a
multiplication can hardly be described as complex.

Best regards,
 Chris                            mailto:chris@w3.org
Received on Monday, 14 October 2013 21:56:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:47 UTC