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