|
From: Pierre A. <pie...@op...> - 2004-06-18 09:00:37
|
Stephan Assmus wrote:
>> It might be. Although, the formulae (yours and mine) are essentially
>> the same.
>> I just optimized it to use one MUL instead of two. t*a + b*(1-a) is
>> the same as b+(t-b)*a (in terms of 0...1 range). There might be
>> slight difference with rounding, tho. But even if it's incorrect,
>> you can always replace it with your own, not modifying existing
>> (possibly wrong) code.
>
> I think you're wrong assuming only top alpha counts. Consider the case
> of bottom alpha to be 0. This is by implication an invalid or undefined
> color. If by pure chance the bottom color resembles black, you're
> blending to black background, where as you really should just assign
> the top color to the pixel ignoring the bottom color completely. The
> situation stays the same for increasing bottom pixel alpha, the
> influence of the bottom color should be wheighted by the bottom alpha.
> Of course for rgb24, you're code is absolutely correct, as there is no
> such thing as bottom pixel alpha. For rgba32, there should be an
> additional case.
Oh ! Great, I had not thought about that. And yes, indeed, I had to
struggle with the current implementation of the alpha composition done
by AGG, when working on fully transparent backgrounds. I had observed
problems with the anti-aliasing (or any other pixels with a source
alpha other than 1) being too dark.
Your explanation seems to be adequately describing what I had observed.
> When blending pixel J over pixel I, you could say that J allows (1-b)
> percent of pixel I to shine through. Thus, the formular for correct
> alpha blending is this:
>
> C' = B' + (1-b)A'
>
> C' = b*B + (1-b) * a*A
>
> C is optained by dividing C' by the resulting alpha c which is optained
> by
>
> c = b + (1-b) * a
I finally got what I wanted by pretending that the output pixmap
computed by AGG was alpha-premultiplied, and now my code in Win32
works. I don't remember too clearly how I got to that result, though.
Pierre
|