Problem with blending edges of connected shapes

As you can see there is a brighter line between the two rectangles. I
know where it is from - this is a result of alpha blending of two
partially covered scanlines. And this is a problem form me.

Do you have any idea how to get rid of this line? I mean how to make
it in the same color as the rectangles. My application draws metafiles
and sometimes there are such shapes in them and I get ugly banded
drawings... Do you have any ideas?

 it's a well known problem that can't be eliminated easily. It exists in
all SVG engies and appears as thin "web" upon the image, when you draw adjacent
shapes:http://www.antigrain.com/svg/index.htmlSay, initially you have color (0,0,0). Then you draw a white pixel on it with
0.5 opacity (which is equivalent 0.5 of pixel coverage). You will have
(0.5,0.5,0.5) which is correct. Then you draw another pixel upon it, also with
opacity=0.5. According to the color blending rules you will have
(0.75,0.75,0.75), not (1,1,1). This is what happens when you draw your
rectrangles.
The problem can't be easily solved. In the SVG example I use conv_contour to
dilate all polygons. But this solution isn't perfect and kinda unfair.

But you can't render a multicolor scene in such a way. It's possible only in
Macromedia Flash, but it requires not only another rasterization algorithm, but
also changing the whole data model. Your data shall be represented not as a set
of polygons, but as a set of edges with attributes - color on the left and
color on the right.

> Say, initially you have color (0,0,0). Then you draw a white pixel on it with
> 0.5 opacity (which is equivalent 0.5 of pixel coverage). You will have
> (0.5,0.5,0.5) which is correct. Then you draw another pixel upon it, also with
> opacity=0.5. According to the color blending rules you will have
> (0.75,0.75,0.75), not (1,1,1). This is what happens when you draw your
> rectrangles.

This is the color from the original post:

> >         ren_aa.color(agg::rgba(0.4, 0.3, 0.2, 1.0));

The opacity of the color is 1.0, not 0.5. So what Maxim tried to say is I 
guess something like this: "Then you draw a white pixel on it with 0.5 
pixel coverage (which is equivalent to 0.5 opacity)."

Now, forgive me for my ignorance if this is trivial, I really haven't had 
to think about this particular problem, but here's an idea: suppose you 
are doing a flash-like multicolor fill where you know that no polygon 
overlaps another (triangulation, tesselation, whatever). Can the blending 
rule in AGG be changed so that the alpha channel is not interpreted as a 
genuine alpha, but as a coverage percentage instead? So that for example 
in this particular case 0.5+0.5 would be 1.0? This wouldn't work if you 
also want alpha, but the presumption here is that you really don't need it.

> Now, forgive me for my ignorance if this is trivial, I really haven't had 
> to think about this particular problem, but here's an idea: suppose you 
> are doing a flash-like multicolor fill where you know that no polygon 
> overlaps another (triangulation, tesselation, whatever). Can the blending 
> rule in AGG be changed so that the alpha channel is not interpreted as a 
> genuine alpha, but as a coverage percentage instead? So that for example 
> in this particular case 0.5+0.5 would be 1.0? This wouldn't work if you 
> also want alpha, but the presumption here is that you really don't need it.

Actually, that's an idea, I'm not sure it's doable, but it's seems to be. One
pixel can be overlapped by many polygons even if the polygons themselves do not
overlap. 
http://antigrain.com/stuff/multipoly_cover.gif - the central pixel is covered
by 6 triangles. It means that there are 6 different cover values and 6 colors.
And the resulting color must be calculated as the weigted average, where weight
is coverage. But we should keep a whole list of coverage values for each pixel!


Another solution is to use the alpha channel for coverage values. Suppose we
have not RGBA, but RGBC color space. Initially all cover values are 0. At a
time we always operate with 2 colors and two coverage values. We accumulate the
coverage values (with clipping at 1.0) and calculate the resulting color as the
weighted average of 2 colors/covers. It looks very familiar, and remainds me
the formulae for alpha blending in plain (non-premultiplied) color space.

> And the resulting color must be calculated as the weigted average, where weight
> is coverage. But we should keep a whole list of coverage values for each pixel!

Assume for example that you have calculated values

  nom = (w1*a1+w2*a2+w3*a3)/(w1+w2+w3)   (the weighted mean so far)
  den = w1+w2+w3                         (the sum of weights so far)

Then you can calculate new values

  nom = (nom*den + w4*a4)/(den+w4)
  den += w4

Expanding those formulas you will get the correct results. That is, you do 
not need to keep a record of all the colors in order to calculate an 
update to the weighted mean, the mean so far plus the weight (kept in 
alpha) is sufficient.