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> 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]
> *Sent:* Monday, February 20, 2012 1:11 PM
> *To:* Leonard Rosenthol
> *Cc:* Rik Cabanier; Chris Lilley; Erik Dahlstrom; 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>
> 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
> *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
> *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> 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]
> *Sent:* Thursday, February 16, 2012 4:45 PM
> *To:* Chris Lilley
> *Cc:* Erik Dahlstrom; 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> 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****
>
>  ****
>
>  ****
>
> ** **
>