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
>
> ****
>
> ** **
>