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

[Stephan A. <sup...@gm...>]

Hi Maxim,

> Yes, your "linear" alpha-blending does look much better than what we 
> use now in
> AGG. I suppose the difference in performance is because you use "v/
> 255" rather
> than "v>>8". It works much much slower. But the problem is "v>>8" is 
> "v/256"
> which is theoretically incorrect, but in practice the difference is 
> not
> noticeable. The only case we should process separately is when alpha 
> is 255.

I have that one covered as "special case" anyways. This is unclear to 
me in your code.
There should actually three cases:

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.

I will see how much speed up I get by replacing /255 with >>8.

> I think your idea with gamma for each channel is great! It definitely 
> worth
> having a modified version of the pixel format renderers. I'm not sure 
> if we
> need to use a LUT of 25500 values while actual precision of the color 
> space
> remains 8 bits per channel, but I'll need to experiment with it. You 
> multiply
> your "top" colors by 100, right? Why not by 256 then? 

They are not exactly multiplied by 100. See my init_gamma() function 
for how I fill the LUTs. I use 100 times the precision just to keep the 
RGB->R'G'B' LUT smaller. This LUT has 25500 entries now instead of 
65280 as you propose. Since the purpose is to get a little better 
resolution for the initial gamma conversion (R'G'B->RGB), it should be 
sufficient. You see if you convert 8bit to 8bit with a gamma function, 
you loose a lot of resolution, since many values round up to the same 
value after the conversion. With 100 times the resolution, I keep more 
detail for the blending calculation and hope to still see this after 
converting into normal R'G'B'.

> Actually, it's possible to implement any color space you want. For 
> example, you
> use agg::rgba (with doubles inside), but work with an 8-bit-per-
> channel canvas.
> AFAIU it's similar to your multiplied by 100 values.

agg::rgba? Where do I find that?

> BTW, with this LUT we can avoid using divisions and obtain more 
> correct result
> with the shift operation. We need just to consider this feature when
> initializing the LUT.

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

> Where did you get that 2.2 gamma value? Is that kind of average 
> standard for
> human vision?

I think it is avarage standard for PC monitors, ie the graphics card is 
supposed to be setup that way on PCs. On Macs it is different, IIRC 
1.8.

Best regards,
-Stephan