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

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

Speaking of the feComposite filter, it is important to note that the
arithmetic k values can be negative or larger than 1. My Solar Flare
example[1] is broken in Firefox and WebKit (works in Opera), I believe,
do to this. This should be more explicitly noted in the spec; there is a
test case (filters-composite-03.f.svg) for it for which only Batik and
Opera pass.[2]

     Tav

[1] Last example at:
http://tavmjong.free.fr//INKSCAPE/MANUAL/images/FILTERS/index_complex.xml

[2]
http://www.w3.org/Graphics/SVG/Test/20110816/status/implementation_matrix.html



On Mon, 2012-02-20 at 14:45 -0800, Rik Cabanier 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
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
>

Received on Tuesday, 21 February 2012 08:37:27 UTC