Re: MASKING AND COVERAGE: AGAIN

Thanks for your patience and answers. I can now proceed fully. I will
simply apply the opacity after the composite operator and it is then
the correct order. What I have been referring to as the "global alpha"
then becomes something else, almost as if there was another step to
blending and compositing. Like a "alpha fx" step that happens just
before the blending operator is applied. Simply an fx on the incoming
pixels alpha value much like the blending step is an fx on the
incoming pixels rgb values.

On 8/7/12, Rik Cabanier <cabanier@gmail.com> wrote:
> On Tue, Aug 7, 2012 at 9:36 AM, Bob Holmes <rangsynth@gmail.com> wrote:
>
>> So your original reply that masking cannot be combined with opacity is
>> correct as you stated. So I specified the question or concept
>> incorrectly to begin with. What I was referring to was simply a
>> function of alpha adjustment as the first step of compositing the
>> pixel. The global alpha I have referred to is then not the same value
>> as the "opacity" of groups etc...
>>
>> And again the reason I brought it up...
>>
>> Example: Fill A Polygon
>> 1) The polygon mask/raster produces lines of alpha values where the
>> polygon is visible. I call this the mask value. In RGBA from 0 to 255.
>> Antialiased polygons for example have less than 255 values at the
>> edges.
>> 2) Where the value is not zero, the source pixel is fetched from the
>> source ink or source bitmap or whatever you want to call it.
>> 3) then the source pixel and the mask value are sent together to the
>> compositor.
>>
>> Because I have the "mask value" from the polygon(but could just as
>> easily be from a bitmap), and I also have a global value to apply to
>> alpha of all incoming pixels in the compositor, and because there are
>> premul considerations, the optimizations are more because the values
>> can be combined. Like for SrcOver with normal blending a premultipled
>> input can be multiplied once with the result of multiplying the mask
>> value and what I was referring to as global alpha. If I did the
>> multiply of the pixel with the mask value before entering the
>> compositor it would require extra instructions.
>>
>> I hope that is clear and explains more fully what I was asking.
>>
>
> Yes, you can optimize your code this way, but you have to be careful.
> Alpha on the group is applied after masking, filtering and blending. So, if
> there is a filter or blend mode, you can no longer do this optimization
> since it will affect how your group will render.
>
> Rik
>
>
>>
>> On 8/7/12, Rik Cabanier <cabanier@gmail.com> wrote:
>> > 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 19:34:43 UTC