[AGG] Blending (again) [resend]

[Michael D. <md...@st...>]

[This is a resend of an email that was rejected for size].

I’ve gone ahead and upgraded matplotlib from agg-2.4 to current agg SVN. 
Overall, pretty painless, thanks.

However, I’m running into one problem that is resulting in all the 
colors being slightly off from before.

The rendering buffer is of type agg::pixfmt_rgba32_plain, and it’s 
initialized to all zeros.

In agg-2.4, if I draw a rectangle path with RGB value of (0, 255, 102, 
64), the resulting pixel value is (0, 255, 102, 64).

In agg-svn, I get (0, 255, 104, 64).

This slight difference has cumulative effects that are not desirable.

I’ve tracked down the difference in code to blender_rgba_plain::blend_pix.

In agg-2.4, I have:

Inputs:
p = {0, 0, 0, 0}
cr = 0
cg = 255
cb = 102
alpha = 64

Therefore:
a = ((alpha + a) << base_shift) - alpha * a;
a = 16384

p[G] = ((((cg << base_shift) - g) * alpha + (g << base_shift)) / a)
g = 102

I’m having trouble tracing the order of execution in the SVN version of 
Agg, but it seems the difference is not so much in anything intentional 
but from the fact that everything but the final demultiply is downgraded 
to color_type, and then the demultiply happens. Whereas in the old 
version, it’s still doing calculations in calc_type (uint16) up until 
the final demultiply.

Does that make sense, or am I doing something wrong?

I’m using a non-premultiplied buffer, because ultimately these things 
are saved to PNG, which wants non-premultiplied data. I tried changing 
to a pre-multiplied buffer, and then demultiplying immediately before 
saving to the file, but that has the same numerical issue as far as I 
can tell.

Mike

-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute

http://www.droettboom.com