[Bf-committers] Color Unpremultiply

[Brecht Van Lommel]

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. It's easy to verify that if you do compositing after
conversion to sRGB, it will give a different, and so a wrong result.

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.

Now, on the web, you are commonly doing this kind of wrong compositing
in sRGB space with PNG images, and it will usually not look too bad.
Look e.g. here. It's not possible to know what the intended colors
were here, but if you can see that composited over white/yellow the
colors look a bit crappy greyish in the semi-transparent areas.
http://www.w3.org/Graphics/PNG/inline-alpha-table

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.

Brecht.

On Sat, Feb 18, 2012 at 7:45 PM, Troy Sobotka <troy.sobotka at gmail.com> wrote:
> 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.
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers