[cairo] Premultiplied transparency causes streaks in images

[Paril]

The black halo isn't black in a colored image, I was talking about in the
white image, which I understand because of how premultiplication works (1 1
1 1 * 1 1 1 0.5 = 0.5 0.5 0.5 0.5); with the different colors it changes
around, but yes, you are right, it's more like a multicolored halo.

I get what you mean with the error accumulation, but what else can I do
here? There's no Cairo function, that I can tell, to use SetSourceColor when
SetSource on a pattern is used, hence why I do the color stuff manually, and
I still have to multiply the values to get the bitmap together for Cairo to
use properly. The _fixed.txt you had attached before seemed to just lighten
the transparency and make it less visible, but the streaks are still
definitely there.

Your explanation of errors makes complete sense to me because when I look at
it, the streaks barely occur when the color values are 0, 0.5 or 1; any
value in-between and you can see the streaks on a huge scale, but with those
three values you see maybe one or two points off the color.

Cairo only supports integral colors, so there will be rounding errors with
all of this multiplication... do you have any ideas on what I can do?

-P

On Fri, Nov 12, 2010 at 6:44 AM, Andrea Canciani <ranma42 at gmail.com> wrote:

> On Fri, Nov 12, 2010 at 11:32 AM, Paril <paril at alteredsoftworks.com>
> wrote:
> > The fixed code you provided outputs a single dot (you forgot the Paint()
> > call, but I extrapolated), which appears fine when you look at it at face
> > value, but again, if you re-add that loop I had in the first place you
> see
> > the transparency around the corners of the circle creating black streaks.
> > This is the problem.
> >
> > If you weren't able to see the output, here it is:
> > http://alteredsoftworks.com/cairo/output.png
>
> If you zoom in http://alteredsoftworks.com/cairo/output.png you will
> see that some "incorrect" pixels are more greenish than the expected
> color (in particular, the streaks are not just black, confirming that my
> explanation of the problem is probably correct).
>
> >
> > Here's a slightly modified version with no y modification. This shows you
> > the clear black outline when the brush is continuously drawn in one spot:
> > http://alteredsoftworks.com/cairo/output_red.png
>
> Actually if I zoom in I see clearly that there is *no* black outline.
> I see these shades: red, dark red, fuchsia, brown, purple, blue, green-blue
> (Uhm... I'm not a native English speaker, so I might be misusing the color
> names... anyway my point is that I see no black).
>
> >
> > I don't entirely understand your explanation; the only time you can
> really
> > tell that it's happening is when you are drawing a bunch of lines around,
> > hence why in the example I drew a capsule shape.
>
> A "simpler" (and much less detailed) explanation is:
> Premultiplication amplifies the quantization error of the color components
> Compositing multiple times pixels accumulates the error
> (so if you want to do it, you need to make sure that the error of the image
> you are compositing is small enough)
>
> On Fri, Nov 12, 2010 at 12:31 PM, Paril <paril at alteredsoftworks.com>
> wrote:
> > ...
> > I expected that the data (as from my understanding with premultiplied
> alpha)
> > would somehow be de-multiplied back into the original
> white-and-transparent
> > one (which apparently.. makes it do less operations? I really don't
> > understand the whole concept, and from my googling a lot of people come
> to
> > the same conclusion, probably just due to lack of understanding why
> > premultiplication is important). This was not the case, and what Cairo is
> > showing ALSO contains the black outline, which leads me to concur that
>
> Does the black outline appear in test.png even if you use cairo functions
> to save as png?
>
> > Cairos' usage of the premultiplication is causing the image to draw this
> > black halo in the transparent portions of the image.
>
> There is no black halo, the "multicolor" halo is caused by error
> accumulation.
> Premultiplication makes it more evident, but the problem is that you expect
> that compositing 100 times a 1% opaque image is the same as compositing
> the "same" image at 100% opacity. This assumption doesn't hold if you use
> integer components because of quantization errors.
>
> Andrea
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cairographics.org/archives/cairo/attachments/20101112/a3ea75b3/attachment.htm>