Re: [AGG] Blending colors, associated alpha, etc

[Maxim S. <mcs...@ya...>]

Hi Stephan,

I could reproduce your result with 0...255 range. Yes, it might be 
less accurate, but it looks exactly the same as in your "linear" blending
picture.

Below is an example of one function for 24-bit true color. I believe for
alpha-channel there shouldn't be any changes, that is, alpha should be
processed as before.

//--------------------------------------------------------------------
void blend_solid_hspan(int x, int y,
                       unsigned len, 
                       const color_type& c,
                       const int8u* covers)
{
    int8u* p = m_rbuf->row(y) + x + x + x;
    do 
    {
        int alpha = int(*covers++) * c.a;
        if(alpha)
        {
            if(alpha == 255*255)
            {
                p[Order::R] = (int8u)c.r;
                p[Order::G] = (int8u)c.g;
                p[Order::B] = (int8u)c.b;
            }
            else
            {
                int r = m_dir_gamma[p[Order::R]];
                int g = m_dir_gamma[p[Order::G]];
                int b = m_dir_gamma[p[Order::B]];
                p[Order::R] = m_inv_gamma[(((m_dir_gamma[c.r] - r) * alpha) +
(r << 16)) >> 16];
                p[Order::G] = m_inv_gamma[(((m_dir_gamma[c.g] - g) * alpha) +
(g << 16)) >> 16];
                p[Order::B] = m_inv_gamma[(((m_dir_gamma[c.b] - b) * alpha) +
(b << 16)) >> 16];
            }
        }
        p += 3;
    }
    while(--len);
}

> 1: top alpha == 255 or bottom alpha == 0, resulting color = top color
> 2: bottom alpha == 255, equation is much simpler, in fact it is what I 
> think you're doing
> 3: bottom alpha != 255, here we have to use a different equation, and I 
> think you're not handling this correctly.

There are 3 cases, but there is only "top" alpha counts. If it's 255, it's
opaque, including alpha, if it's 0 it doesn't have any effect. Intermediate
values blend.

> 3: bottom alpha != 255, here we have to use a different equation, and I 
> think you're not handling this correctly.

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.

> agg::rgba? Where do I find that?

agg_color_rgba.h

> You mean when using floats? But using floats usually means a huge 
> performance impact. I'm probably misunderstanding you.

No, you use floats only to define colors for solid filling. Inside the
blend_solid_span you use integers as before. I'm not sure if it makes much
sense, tho. It's just an example of how you can organize your color spaces.

I'll try to add new pixel format renderers with gamma correction soon.

McSeem


McSeem