RE: Color Math (was RE: Agenda, 16 February 2012 SVG WG telcon)

What is the next step?
Should we bring it up as a topic on the SVG meeting and if accepted, annotate the filters spec?

Rik

From: Alex Danilo [mailto:adanilo@google.com]
Sent: Monday, February 20, 2012 2:58 PM
To: Rik Cabanier
Cc: Leonard Rosenthol; Chris Lilley; Erik Dahlstrom; public-svg-wg@w3.org
Subject: Re: Color Math (was RE: Agenda, 16 February 2012 SVG WG telcon)

Hi Rik,

Yes, I agree with your conclusion about the clamping ranges.

The clamping comment also affects Porter-Duff 'plus' which is part of the comp-op/blend-mode/shape-mode proposals.

Alex
On Tue, Feb 21, 2012 at 9:45 AM, Rik Cabanier <cabanier@adobe.com<mailto:cabanier@adobe.com>> wrote:
Alex,

Sorry but L<0 or L>100 is invalid and should not be used to do color calculations. I'm sure the math might give you reasonable results, but it is not right.

Moving back to the original email that started this conversation, you claim that intermediate values that are negative or greater than 1 are fine.
Reading the SVG spec for feComposite:
                This filter performs the combination of the two input images pixel-wise in image space using one of the Porter-Duff compositing operations: over, in, atop, out, xor. Additionally a component-wise arithmetic operation (with the result clamped between [0..1]) can be applied

so, it seems that the spec writer was aware of this issue.
I believe this is an oversight because the author forgot that we were in premultiplied alpha space (which also not belongs in the spec imho).
I agree with Stephen Chenney that the spec should read:
                With the result clamped between [0..1] for the alpha value and [0...alpha] for the color values

I agree with you that having intermediate values that are not colorimetrically correct is fine.
However, these intermediate values should not the input or output of a SVG filter.

Rik

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

A value of L > 1 in an Lab color space is valid and may not be representable by an ICC profile. You are talking about 2 different things - able to be processed by an ICC color model engine, and out of gamut.

Regardless 1 + 2 - 2 = 1 although the intermediate results can peak at 3 is what this is supposed to be discussing.

Alex
On Tue, Feb 21, 2012 at 2:22 AM, Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>> wrote:
Colors outside the current profile (which may be the default sRGB or may be an arbitrary one if the icc-profile() is used) are indeed invalid.

Leonard

From: Rik Cabanier
Sent: Sunday, February 19, 2012 10:57 PM
To: Leonard Rosenthol; Alex Danilo
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

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<mailto: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]<mailto:[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<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