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

Re: MASKING/COVERAGE ETC...

From: Bob Holmes <rangsynth@gmail.com>
Date: Mon, 6 Aug 2012 23:25:30 +0200
Message-ID: <CAMvo67a6eBw-jQnHconR3+SBucKLeo=+D-7FaBcjToe=GoD8tw@mail.gmail.com>
To: Rik Cabanier <cabanier@gmail.com>
Cc: Nikos Andronikos <Nikos.Andronikos@cisra.canon.com.au>
THIS IS A RESEND TO THE GROUP.

On Mon, Aug 6, 2012 at 11:00 PM, Rik Cabanier <cabanier@gmail.com> wrote:

>
>
> On Mon, Aug 6, 2012 at 9:24 AM, Bob Holmes <rangsynth@gmail.com> wrote:
>
>> I am just now actually implementing this so I have this way of drawing
>> where the lines are rasterized with a mask value. Sometimes per pixel
>> but also for the width of a polygon for example. Like in AGG or
>> similar to masking maybe in libpixman.
>>
>> So I see in agg that they combine the masking for operators like SrcIn
>> to actually use the mask value to affect the output with the
>> destination. This does not make sense.
>>
>
> Depends on what you call masking. Is it alpha or luminosity masking? Most
> people want luminosity which is more than simple src-in.
>
>
>>
>> Seems to me that if you have a masking value that it should simply be
>> combined with the alpha value of the source color before the blending
>> step. In addition to this a global alpha value could also be included
>> in this step.
>>
>
> I'm unsure if we call out when masking happens...
>
>
>>
>> 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 do you think? The specification is only touching on coverage as a
>> function of ource and destination alphas but makes no mention of
>> coverage as it would be affected by a masking value, such as the
>> masking value that a polygon mask might output.
>>
>
> Yes, I will talk to some people and will update the spec.
>
>
>>
>> In libpixmap they have per channel masking. Is this concept also being
>> planned to be included in the specification?
>>
>> No, the current formulas treat all channels the same.
> If there's a need, we can add it later. If at that point, we have
> programmable blending and compositing, those will be address that use case.
>
> Rik
>
>
Received on Monday, 6 August 2012 21:25:59 GMT

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