RE: Agenda, 16 February 2012 SVG WG telcon

If you aren't using ICC profile (and an associated CMM) for conversion, but instead are relying on something like the "Red Book algorithms", then yes, you clamp - it's part of the algorithm definition.  Same is also true for things such as the various transparency blending algorithms - they also included clamping.

Leonard

From: Rik Cabanier [mailto:cabanier@adobe.com]
Sent: Sunday, February 19, 2012 11:13 PM
To: 'Alex Danilo'
Cc: Chris Lilley; Erik Dahlstrom; public-svg-wg@w3.org
Subject: RE: Agenda, 16 February 2012 SVG WG telcon

Hi Alex,

Yes, 16bit fixed point should get you past the loss of precision introduced by the curves.
When going true DIC, a floating point value might be better (or 16/32bit fixed in the color range of the colorspace)

You bring up an interesting point about not clamping intermediate results. The color formulas I've seen always specify or imply clamping so I have to think about that.
I'm pretty sure though that we should not give a meaning to these intermediate values (such as fluorescent).

Rik

From: Alex Danilo [mailto:adanilo@google.com]<mailto:[mailto:adanilo@google.com]>
Sent: Sunday, February 19, 2012 4:03 PM
To: Rik Cabanier
Cc: Chris Lilley; Erik Dahlstrom; public-svg-wg@w3.org<mailto:public-svg-wg@w3.org>
Subject: Re: Agenda, 16 February 2012 SVG WG telcon

Hi Rik,

Yes they are valid results - but not necessarily useful:-)

Implementations usually can't store them - especially if you're using 8-bit per component RGB. So in many cases they get clamped at intermediate stages but certainly there's no color science reason those values aren't legit.

In RGB the > 100% values represent fluorescent colors, i.e. they are brighter than full white, so that could represent a light source fluorescing under sunlight, etc.

When I did filters some time last year I ended up having to move to 16-bit linearRGB space to eliminate banding, and there no reason a color management engine shouldn't be able to handle out of gamut colors etc. by using floats/fixed point or similar.

However, practical considerations may well limit what is nice to process as intermediate results. So I can see why people don't like the idea of unusual values in the intermediate filter results, and the spec. doesn't limit intermediate color values, but clamping to something sensible at the end of the chain may well produce better results than limiting each stage of the pipe.

Alex
On Sat, Feb 18, 2012 at 3:02 AM, Rik Cabanier <cabanier@adobe.com<mailto:cabanier@adobe.com>> wrote:
Hi Alex,

Are you saying premultiplied alpha where the color component are greater than the alpha value (or negative) are valid results?
Even with linearRGB, we are still in the RGB colorspace (not XYZ or some other hypothetical space)...

Rik

From: Alex Danilo [mailto:adanilo@google.com<mailto:adanilo@google.com>]
Sent: Thursday, February 16, 2012 4:45 PM
To: Chris Lilley
Cc: Erik Dahlstrom; public-svg-wg@w3.org<mailto:public-svg-wg@w3.org>
Subject: Re: Agenda, 16 February 2012 SVG WG telcon

+1 to that.

There seems to be some disconnect between what colour management is about recently.

For example the recent thread (on webkit-dev perhaps?) about filters generating colour that's 'illegal' - i.e. the colour channels greater than the alpha in pre-multiplied form is wrong. It's just a fluorescent colour.

We really should ensure we do colour science properly.

Alex
On Thu, Feb 16, 2012 at 11:49 PM, Chris Lilley <chris@w3.org<mailto:chris@w3.org>> wrote:
On Thursday, February 16, 2012, 10:14:36 AM, Erik wrote:

ED> Missed one thing:

ED> * color-interpolation-filters
ED>
ED> http://www.w3.org/mid/CAGN7qDDh_yJX_EzWNtuvW3N_eywgvB3MioMn6FoP_p8kHTwh-A@mail.gmail.com


Are we discussing:

a) how to specify the longhand, element-based equivalent to each of the css shorthand properties (which will include the value of the color-interpolation-filters property,

or

b) whether to remove color-interpolation-filters and color-interpolation, thus breaking backwards compatibility and destroying improvements in color management in SVG2, because of flawed understanding of basic concepts like gamma, chromaticity, and so forth?

If a) then I am all in favour of providing the longhand equivalents and would like to see tests that put the longhand and shorthand side by side so we can check that implementors are doing the right thing.

If b) and we are seriously considering legislating the dumb approach to RGB, then I have strong objections to such a wrong-headed approach.

I can provide links to further reading if people need to brush up on basic concepts.


--
 Chris Lilley   Technical Director, Interaction Domain
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups