Premultiplied colors and alpha=0

Keith Packard keithp at keithp.com
Wed Aug 13 13:24:07 PDT 2008


On Wed, 2008-08-13 at 21:46 +0200, Soeren Sandmann wrote:
> Generally to recover the "real" pixel from a premultiplied one, you
> have to divide by the alpha channel, but this leads to a problem when
> the alpha channel is 0. How should a render implementation treat such
> pixels?

Premultiplied *is* the real color; non-premultiplied is a poser.

The Over operator does

	dst = dst * (1-srcA) + src

That works for any srcA value, even zero. Pixels where any color channel
is greater than alpha are called 'super luminescent' colors.

> Suppose it is compositing a source pixel with alpha 0 and color
> channels non-zero OVER some destination pixel. There are at least two
> reasonable things an implementation can do:
> 
> 1.  "The alpha channel is 0, so the source is transparent, so you just
>      get the destination"

That's always wrong.

> 2.  "I'll do arithmetic as usual, so I'll just add the source color
>      channels onto the destination"

That's always right.

> The advantage of (1) is that you can avoid a bunch of memory reads for
> images that are mostly transparent. The advantage of (2) is that
> special-casing alpha=0 is unnecessary.

You're still reading the alpha values, if the alpha channel is mixed
with the RGB channels, you'll have performed the same number of reads,
even with an uncached source.

> Any opinions?

Nope, just the facts.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20080813/0b25c07a/attachment.pgp>


More information about the xorg mailing list