W3C home > Mailing lists > Public > www-svg@w3.org > August 2012


From: Bob Holmes <rangsynth@gmail.com>
Date: Tue, 7 Aug 2012 12:15:19 +0200
Message-ID: <CAMvo67YynK=5VXD4ujNGDzrPOApEZszyARCkVu_V+L6HC4SV8g@mail.gmail.com>
To: Dmitry Baranovskiy <baranovs@adobe.com>
Cc: Rik Cabanier <cabanier@gmail.com>, Nikos Andronikos <Nikos.Andronikos@cisra.canon.com.au>, "www-svg@w3.org" <www-svg@w3.org>
This helps although I was referring to the concept of a "source mask".
Such as the values produced when drawing a polygon or some text. In
the document the closest thing to it might be the concept of the
"shape" as mentioned slightly in the section on coverage.

So you have a bitmap which is the source pixels, and then the
compositor. So in between is the polygon shape, which I was referring
to as mask. The poylgon values are used to adjust the alpha of the
source pixels.

So the reason I think that the "shape" value should be applied just
before the blending step in the compositor is because of how different
requirements for premul can be combined as one. If the source pixels
are premul and the mask/shape value is not 1, the shape/mask value can
be applied in one multiply when unpremultiplying the source pixel
before the blender step.

If a global alpha property was also present then it can also be
combined together with the mask/shape value and the unpremul for

If you look at libpixman then that is how they are doing it I think.
Agg 2.4 also seems to do the same thing. I just saw in AGG that they
were combining it differently for one or two blend modes and wondered
if it was "a part of the standard". But from the notes on source pixel
shape I think it is not.


On 8/7/12, Dmitry Baranovskiy <baranovs@adobe.com> wrote:
> Hi Bob,
> I guess this is the same thing as using opacity on elements and on the
> group. It behaves differently. And because image is worth a thousand words
> here is an example: http://dmitry.baranovskiy.com/group-masking.svg
> View it in anything, but Safari. Applying mask to each element individually
> cause them to “interact with each other”, while applying it to the group is
> different.
> Hope it helps and I am not stating the obvious.
> best,
> Dmitry
> On 07/08/2012, at 8:10 AM, Bob Holmes wrote:
> I am at the point now where I have zero confusion except this masking
> business vs. grouping. Any further comments would be appreciated on this.
> For modes like DstIn masking would thus have no effect.
> The blend function for RGBA excepts a value from 0 to 255.
> I also have a global alpha value which affects all alpha.
> My theory is that no matter the blend mode or combine mode that source
> pixels can simply have the alpha adjusted by multiplying with both
> global alpha and the mask value, which can optimally be combined prior
> to actually calling into the blenders.
>>>No, if you have grouping, you can't simply redistribute alpha. That will
>>> make the graphics interact with each other which is usually not desired.
> What does it mean "can't simply redistribute the alpha"?
> If I take a masking value of 255 and simply multiply it with the source
> color alpha. The source color does not change. But for the edges of the
> polygon where it is antialiased the mask value might be 64 for example, so
> multiplying that with the alpha of the color and then calling into the
> blender/composite function is surely the way to go?
> Any notes on how the grouping affects this simple alpha masking will help.
Received on Tuesday, 7 August 2012 10:15:52 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:29 UTC