[Bf-committers] Color Unpremultiply

[gespertino at gmail.com]

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

> Hi,
>
> I think we can agree that if you do scene linear => sRGB conversion on
> the final composited image, with no alpha, that will give a correct
> result.


Agreed.


> It's easy to verify that if you do compositing after
> conversion to sRGB, it will give a different, and so a wrong result.
>

Well, not necessarily.
It's true that alpha-over should be done in linear space, but applications
still allow to open non-linear RGBA files (both premultiplied and straight).
As you mentioned, web browsers do alpha blending in sRGB space, GIMP does
it too (questionable or not, it does it), and Photoshop lets you choose
gamma for alpha compositing.
Anyway, I agree that those images should be linearized back for a proper
alpha blending if it was the point.
Question is how to deal with associated alpha in that stage.


> 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)
>
> So, the (R,G,B) in the associated alpha image are already the same as
> they will be in the final composited image, and doing the conversion
> on either will give the same result. That's of course the exception.


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.
so a red pixel with 50% transparency would be in rgba: 0.5,0.0,0.0,0.5
(which is, as you mentioned, the same that compositing that pixel on black).
Dividing that by alpha will give a solid red pixel.

If you convert that linear RGB to sRGB and alpha remains untouched (it has
to), that correlation is broken. You can't get a clean red pixel dividing
the alpha, it will still be contaminated.
That's what Blender has been doing with premultiplied images saved in
non-linear formats until color unpremul was implemented.
The problem wasn't visible in Blender's compositor because when you opened
back those images, they were linearized without pre-dividing alpha, so the
problem was cancelled.

But other applications (at least the ones I tried) seem to expect that
correlation with alpha in sRGB.



> So for me this is more a question of what the best default is, if
> having this enabled for premultiplied alpha images is considered
> better then in principle I have no problem if this gets enabled by
> default. However there is an extra issue which is that currently we
> have no way to know if the image is premultiplied or not. For render
> output maybe to some extent, but even then compositing can change the
> kind of alpha that the render has.
>

Hmm. This is definitely a good point.
Making color unpremultiply default for premultiplied renders would be
problematic if the user already divided alpha because s/he wants to save an
unassociated image (a proper PNG for instance).
However, I still wonder if that checkbox doesn't belong to the compositing
node instead of the shading panel.
Placing it in the shading panel implies that the user already planned if
the output will be associated or unassociated.
Placing that checkbox in the composite node and enabling it as default when
premultiplied rendering is selected would make sense and would be more
discoverable during compositing and therefor harder to miss.