[Bf-committers] Color Unpremultiply

gespertino at gmail.com gespertino at gmail.com
Mon Feb 20 21:36:34 CET 2012


2012/2/20 Brecht Van Lommel <brechtvanlommel at pandora.be>

>
> Maybe the wording needs to be better and I'm happy to change it if you
> come up with a better tooltip, but I disagree that enabling the option
> delivers a "properly converted image". It doesn't, it just looks less
> bad in some situations, it's only a heuristic. From my testing it
> seems that sometimes enabling this option looks better, sometimes it
> looks worse.
>

As I mentioned before, at least with the applications I tried (with the
sole exception of Blender's compositor) they seem to divide alpha before
linearizing premultiplied sRGB.
For the rest of applications that perform alpha compositing in non-linear
space (which is not correct, we agree) the linear premultiplied images that
were unpremultiplied, converted to sRGB, then premultiplied back, always
look better.
Color corrected premultiplied data (Blender's default behavior without
color unpremultiply) always gives fringes when composited on non-linear
space (except, of course, when the color of the background cancels the
fringe, but that doesn't mean that the fringe is not there. It's just
hidden).
In blender it doesn't happen because it linearizes the non-linear
premultiplied images without unpremultiplication. But our non-linear
premultiplied images don't get properly composited in other packages unless
you use the new "color-unpremultiply" feature.

Notice that I'm talking about premultiplied, non-linear files saved from
Blender compositor and opened in other applications.
I'm aware that alpha compositing shouldn't be performed in non-linear space
and most of the 8bpc, non-linear formats aren't suitable for high quality
compositing, but since they exist and are supported by all kinds of
applications, users should have the tools to create proper files.


>
> >> There is one exception, and that is when you will composite over a
> >> black background. Then the associated alpha over formula becomes:
> >> (R,G,B) + (1-A)*(0, 0, 0) = (R, G, B)
> >>
> > Please correct me if I missed something and I didn't get you point, but I
> > think this is wrong.
> > In an associated image, RGB in linear space has a correlation with alpha,
> > which is also in linear space.
>
> Maybe I should have used a better notation, but the conclusion is the
> same, the components are the same in both.
> (R*A,G*A,B*A) + (1-A)*(0, 0, 0) = (R*A, G*A, B*A)
>
> When looking at the image on a black background it will look correct.
> If you look at the image in Blender's image editor without enabling
> alpha display it shows a black background, so not using Color
> Unpremultiply will actually show the correct image there!
>


Again, that works that way in Blender, so it looks good there.
Other applications seem to act different and that's why Blender's
non-linear premultiplied images look wrong in other applications or
non-linear premultiplied images created outside Blender look bad in
Blender's compositor.
I guess it makes sense, if you're going to alpha-blend in non-linear space
to have for instance sRGB values multiplied by alpha instead of having
premultiplied values converted to sRGB.
The holdback matte is the non-linear background image with the inverted
alpha multiplied on it... the foreground should be equivalent to the sRGB
foreground with the alpha channel multiplied to get the blending right.
Premultiplied data converted to sRGB will look worse.


More information about the Bf-committers mailing list