[cairo] alpha blending
spitzak at gmail.com
Wed Mar 25 12:18:47 PDT 2015
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?
More information about the cairo