[Bf-committers] Color space and alpha issues

[gespertino at gmail.com]

> -----Original Message-----
> From: James Ruan <ruanbeihong at gmail.com>

> I don't think the opposite of teaching is hiding. I think we need a
> uniform format for alpha. Artists don't need to know in which format
> there file is stored or processed. Only the well defined result
> counts.

Adopting a recommended format for alpha is good, as long as artists
have control over it across the composite.
However I don't agree that artists don't need to know which format
files use. It's an extremely important factor and you can't assume
which is the correct since different applications (Blender included)
allow to store alpha without respecting formats specifications. And
even if applications would store alpha following specifications, some
formats (like Targa and Tiff, for instance) allow both types of alpha.
You can try guessing, like one of the options in After Effects, but
it's not a bullet-proof method and could misinterpret some files, like
premultiplied files with luminescent colors.

> So giving every node in Node System to choose there input and output
> format is not a good option.

No, it's not for every node in the node system. Just for the
input/output nodes, so the artist can choose, and more importantly to
avoid color management to introduce errors (color management shouldn't
affect alpha channel, and converting premultiplied data does it).

> +1. Good internal representation should store the most info. And
> RGB+mask alpha is the best choice for compositing.

Not when you only need to transform, blur and alpha-over CG
renderlayers, for instance.
Every compositing tree is different and you can't assume which alpha
format is better. Both are needed.
Sticking with unassociated alpha has as many problems as associated
alpha, and some situations are completely impossible with unassociated
alpha (again, luminescent premul).
Apart from that, how do you preserve the original info (I mean
RGB+mask) after some alpha-over or blur nodes?
I wouldn't say that unassociated is the best choice for compositing.
It's one of the two available choices.

> Maybe, we can handle both format by adding a tag in the imbuf, then
> define a RECOMMEND format for certain application (eg. premultiplied
> for rendering buffers). Image that used in other format will be
> converted to the RECOMMEND for only once. This will add a lot of code
> for checking and converting the format of imbuf though. But by using a
> cache, we can find a balance between CPU and Memory (maybe disk
> cache). And it's a good habit to check the input data and outputs to a
> RECOMMEND format (always assuming others doing wrong and do it right
> itself).

That wouldn't be bad, but it's impossible to make it perfect.
This is a simple example showing how easy is to blow it:
I have a straight alpha image flagged as unassociated. It's an image
introduced to the comp using the input>image node.
I want to multiply the diffuse pass from a render layer on my image.
That pass hasn't the renderlayer's alpha channel... how do you flag
it? is it RGB? Is it straight RGBA with fully opaque alpha? is it
premultiplied RGBA with fully opaque alpha?
What's the flag after the multiply operation? Let's say the result
will end up flagged as straight alpha.
Now I want to use the renderlayer's alpha as the alpha channel for the
result of the mix. So I Use a set alpha node. The original RGBA
information was tagged as straight, so I assign a new alpha and it
should stay straight, right?
But it doesn't. Because the diffuse pass I multiplied has a black
background already, and if I'm using OSA the result will be, in
practical terms, the same than a premultiplied image*
So if I keep treating the result as straight alpha I'll get black
fringes in the next alpha-over or blur node, because if those nodes
are aware of the incoming flag, they will pre-multiply the alpha
(because it's needed for those operations) and introduce a double
premul fringe.

*) I stress "in practical terms", I take the liberty to misuse the
term "premultiplied" to point that a difusse pass with the render's
alpha set is pretty much the same than a premultiplied combined of the
same mesh with a diffuse-only material.

> Or we just use the unassociated alpha everywhere since it preserves
> most info and do conversions every time it is needed.
> After all, it should be easy, simple and correct for the users. They
> should not care about in which format their image is stored.

As Francesco said, premul/postdivide is for compositors what topology
is for modelers. Artists should care about it because it's essential
to get good results.
If that isn't important, I don't see why the compositor should be
improved. Unexperienced compositors are already used to compensate
alpha fsckups with dilate/erode nodes, masks, curves and all kinds of
hacks to get visually acceptable results avoiding alpha problems.