Re: alpha blending

That simulate gamma-corrected compositing (in this case a 50% blend).

The images displayed on a screen have a gamma of appx 2.2, which means 
that .5 actually produces the brightness of .5^2.2 or about 0.217.

It is easier to see if instead of averaging you use addition. Say you 
added two images together. It would add .5 and .5 and get 1, which is a 
brightness of 1. But the brightness should be about 2 * 0.217 or 0.435.

You could convert to the brightness, add, then convert back: 
(2*.5^2.2)^(1/2.2) = .685, which is a brighness of 0.435.

But since the hardware can do a mulitplication faster than pow, and 
often has built-in support for a power of 1/2 (ie sqrt), it is faster to 
be less accurate and use 2 as the "gamma": sqrt(2*0.5^2) = .707 which 
has a brightness of .466, which is certainly close enough considering 
all the other errors.

It is pretty easy to modify all the cairo equations to square all the 
colors first, then take the square root of the result. Sometimes the 
math can then be simplified to avoid sqrt. Most likely these should all 
be new compositing operators so existing code does not break.

There are a couple problems:

First there is "coverage" values which are calculated by the filling 
algorithm. These in fact are not gamma corrected, .5 should mean .5. All 
masks and alpha channels are coverage values, in other cases it may be 
impossible to determine the intent. Some code will barf if combining a 
bunch of images with 4 equal channels does not produce 4 equal output 
channels, this is false if the alpha is composited differently, but I 
can't figure out anything to do about this.

Second is premultiplied images. It is difficult to say whether the color 
was gamma corrected before or after the premultiplying, though first is 
much more common (3d renderers sometimes do the second, almost all other 
software like Photoshop does the first). The math should be written to 
assume this, and anything outputting premultiplied images must produce this.

The biggest annoyance is that lots of graphics will break. For instance 
your careful touch-up photoshop edit, if composited atop the original 
image, will have a visible dark edge. I think the only solution is to 
have a whole new set of compositing operators that are gamma corrected.



On 03/25/2015 08:24 AM, James Cloos wrote:
> There was an interesting bug report this week on fdo referencing alpha
> blending algorithms.
>
> It advocates:   blend(x,y) = sqrt((x^2+y^2)/2)
>
> Ie, hypot() normalized so that inputs in [0,1] result in outputs in [0,1].
>
> Evidently at least one BigName platform uses that.
>
> I don't know how it interacts with all of the Porter-Duff ops, but as I
> recall cairo currently just does linear for the alphas, yes?
>
> Any thoughts on whether switch the alpha blending to that normalized
> hypot would benefit cairo?
>
> -JimC
>
-- 
cairo mailing list
[email protected]
http://lists.cairographics.org/mailman/listinfo/cairo