RE: Agenda, 16 February 2012 SVG WG telcon

Leonard,

so do you agree that colors outside the normal RGB range are invalid?

His colorspace is sRGB which means that his profile is created from/for colors that can be displayed by the monitor.
Doing math with colors that fall outside that boundary, is invalid and will produce incorrect results.
In this case, he should be working in more complete colorspace (like lab). Of course, few clients actually want this, just like few want a DIC workflow.

Rik

From: Leonard Rosenthol
Sent: Sunday, February 19, 2012 7:21 PM
To: Alex Danilo; Rik Cabanier
Cc: Chris Lilley; Erik Dahlstrom; public-svg-wg@w3.org
Subject: RE: Agenda, 16 February 2012 SVG WG telcon

There's a difference between a color being out of gamut and a color not being valid for a given profile.  And it also depends on whether it's a LUT-based profile or a calculated profile.  So if you are going to base your color model around that of the ICC (which would make sense, since it's the industry standard for color management), then you need to be sure to map to that model.

If you want to be future looking in terms of color, then look at Spectral color models - which is where ICC.2 is headed.

Leonard

From: Alex Danilo [mailto:adanilo@google.com]
Sent: Sunday, February 19, 2012 7:03 PM
To: Rik Cabanier
Cc: Chris Lilley; Erik Dahlstrom; 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