[Bf-committers] Color Unpremultiply

Troy Sobotka troy.sobotka at gmail.com
Sat Feb 18 19:45:53 CET 2012


I always feel like a low rent chess player speaking with a grandmaster when
I am speaking with Brecht, but I believe there is some inaccurate
information here.

So here goes...

On Feb 17, 2012 12:42 PM, "Brecht Van Lommel" <brechtvanlommel at pandora.be>
wrote:
> The problem is that it's not actually true that this is always the
> correct thing to do.
[...]
> If you're compositing over a black background, leaving this option off
> will give the exact correct result.

To the best of my knowledge, this statement is fundamentally incorrect.

In all non-linear associated alpha (premultiplied) formats, the RGB values
are in fact associating both emission / occlusion and a color component.

The net sum of this is that _all_ linearizations on assocaited alpha RGB
non-linear values are incorrect[1], irregardless of the background you
intend to perform the over upon. Why? Because the RGB values themselves,
directly out of the file, are exactly as explained above; a hybrid
associated combination of occlusion / emission and RGB color.

I will do my best to explain this in images if I can find some time today.

As to how to determine default behavior, it is not easy because we are
faced with both non-linear (EG: TIFF) and linear formats (EG: EXR) as well
as the combination of associated versus unassociated alpha. The inherent
nature of Blender's image loading code with correct flagging and
granularity is the issue.

With respect and hopefully not looking like a complete fool here,
TJS

[1] It should be considered more coincidence that 0.0 and 1.0 happen to be
identical in pre-linearization and post-linearization, rather than any
degree of overlapping logic.


More information about the Bf-committers mailing list