W3C home > Mailing lists > Public > www-svg@w3.org > November 2010

[ISSUE-2335] feConvolveMatrix bias property in SVG 1.1 SE

From: Anthony Grasso <Anthony.Grasso@cisra.canon.com.au>
Date: Wed, 10 Nov 2010 01:06:27 +0000
To: Jasper van de Gronde <th.v.d.gronde@hccnet.nl>, "www-svg@w3.org" <www-svg@w3.org>
CC: W3C SVG Public List <public-svg-wg@w3.org>
Message-ID: <923A4276C1903646BE5299CA8462B0A013CBAF69@EXM01-WVP.cisra.canon.com.au>
Hi Jasper,

I was given ACTION-2900 [1] to investigate the bias attribute.

As you're aware the specification currently says when preserveAlpha="false" to apply the convolution to all channels. Currently in the specification, the formula to do the convolution for that case is:

cR = (cF * kernel)/divisor + bias
aR = (aF * kernal)/divisor + bias

I agree that the definition of 'bias' is not clear at all and should be changed.

Regarding how it is used in a filter mathematically, your options listed below do not take into account the filter 'divisor' that the current formula does. I would like to know where you think the 'divisor' value fits in with your options that you have specified.

Cheers,
Anthony

[1] http://www.w3.org/Graphics/SVG/WG/track/actions/2900


> -----Original Message-----
> From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf
> Of Jasper van de Gronde
> Sent: Wednesday, 23 June 2010 5:55 PM
> To: www-svg@w3.org
> Subject: feConvolveMatrix bias property in SVG 1.1 SE
>
> I would really like the bias property clarified in SVG 1.1 SE. The
> problem with the current explanation is that it seems to be
> contradictory (and if you take the most explicit explanation, frankly
> not that useful).
>
> In the explanation of the property it is said to be intended to have
> (as one possibility) a gray zero response. However, in the basic
> convolution formula the bias is added directly to the premultiplied
> color values. If you follow this definition the bias property does not
> give you any effective control over the zero response! Depending on the
> alpha component a bias of 0.5 could be anything from out-of-range white
> to 0.5 gray.
>
> We've discussed this problem before and the last post in that thread
> that I could find was by me (on Nabble, as my laptop, with a lot of my
> e-mails is being serviced) and summarized the progress as follows:
>
> <quote>
> For reference, the pseudo-code in the SVG  specification suggests the
> following (preserveAlpha=false):
> -------------------------------------
> Option 1:
>     aF = filtered alpha without bias
>     cF = filtered (premultiplied) color without bias
>     aR = aF + bias
>     cR = cF + bias
> -------------------------------------
>
> I previously suggested:
> -------------------------------------
> Option 2:
>     cR = cF + bias*aR
> -------------------------------------
>
> You seem to suggest:
> -------------------------------------
> Option 3:
>     cR = cF + bias*(aR-bias)
> -------------------------------------
> I'm not sure what the advantage of this would be though. For example,
> if you have a uniformly colored shape (opacity also uniform) and apply
> the filter -1 1 (with bias=0.5) I would expect a response of
> (0.25,0.25,0.25,0.5), and not (0,0,0,0.5).
>
> Another option would be to do an explicit conversion from and to
> premultiplied colors:
> -------------------------------------
> Option 4:
>     cR = (cF/aF + bias)*aR
> -------------------------------------
> Conceptually this might be cleaner, but it does have the disadvantage
> of needing a division. Specifically, what color should result if aF=0?
> </quote>

The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.
Received on Wednesday, 10 November 2010 01:07:06 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:46 GMT