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

Re: MASKING AND COVERAGE: AGAIN

From: Rik Cabanier <cabanier@gmail.com>
Date: Tue, 7 Aug 2012 08:23:50 -0700
Message-ID: <CAGN7qDAQ7w-OPDhm2fBpeNtqkrmejyZtSaJre9Fq1N4aWY0kgQ@mail.gmail.com>
To: Bob Holmes <rangsynth@gmail.com>
Cc: Dmitry Baranovskiy <baranovs@adobe.com>, Nikos Andronikos <Nikos.Andronikos@cisra.canon.com.au>, "www-svg@w3.org" <www-svg@w3.org>
Hi Bob,

is your point the following:
- if I have an image with alpha that I want to use as a mask
- if I have a alpha on the group/shape that I want to mask
Then:
I can multiply that global alpha with the mask alpha.

Rik

On Tue, Aug 7, 2012 at 3:15 AM, Bob Holmes <rangsynth@gmail.com> wrote:

> 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
> example.
>
> 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.
>
> Thanks.
>
> 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.
> >
> > MY ORIGINAL COMMENT
> > 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 15:24:22 GMT

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