[Oiio-dev] Handling unassociated alpha

Brecht Van Lommel brechtvanlommel at gmail.com
Sun Dec 18 18:09:11 PST 2011


Background: there is some discussion going on now about picking an
internal alpha format convention for Blender, and the question about
the consequences of  either format came up.

On Sun, Dec 18, 2011 at 8:38 PM, Larry Gritz <lg at larrygritz.com> wrote:
> I'm not sure I know which operations you mean.  Can you give some examples of operations where you'd need to operate on the "unassociated" values?  And how you'd deal with the fact that the set of color/coverage tuples representable by associated values is a superset of what is representable by unassociated, what do these operations do with the values not representable (like my transparent but incandescent yellow)?

Color correction operations often work better on unassociated RGB
values, or at the least, more like artists would be used to them in
painting applications. Another example would be blurring just the
alpha channel to feather edges, if you decompose/compose RGB and A
channels, unassociated values make this work out right.

Color space conversion may also work better on unassociated values,
but it depends on the situation, the missing background color
information makes this ill defined. For typical png input/output,
doing the conversion on unassociated values seems to be the a safer
default (but that is hand-wavy).

Regarding values that are not representable, a second layer / render
pass for emission could be used. Users may find it easier to think of
images as color + mask and get confused by some of the 'side effects'
of associated alpha, and might rather have something that works more
like painting apps and do some operations with more steps / layers.

I wouldn't want to argue against associated alpha though, mainly tried
to explain cases where you'd need to use unassociated values.

Brecht.


More information about the Oiio-dev mailing list