[Bf-committers] Color space and alpha issues

[gespertino at gmail.com]

I'm very glad this issue is finally getting the attention it deserves!

>> If it does, it makes more sense to go with added complexity and force
>> the artist to learn the ins and outs of alpha for certain operations.
>>
> As usual I'm more for the teaching rather the hiding :)
> As Matt said, only comp expert are going to want to mess with this anyway
> (I'm even sure some expert will bypass it in some cases). But people who
> wants to get serious about it will have to learn it no matter what with any
> application out there

I'm not a comp expert but I'm happy that I had to learn how to deal
with associated/unassociated alpha to get my composites right, mostly
because I use OSA a lot and AA artifacts are pretty visible there if
you do things wrong.
I'm pretty comfortable with the alpha convert node and I'm all for
keeping it and teaching people to use it instead of hiding the tricky
part.
The compositing books I've read mention this (I mean the differences
about premultiplied/straight alpha and when to use them), other
compositing apps have premul/unpremul nodes and alpha selectors in I/O
nodes. I think it's pretty basic compositing knowledge and Blender
shouldn't mask it but make it more obvious and let the user decide.
It has been discussed to flag the alpha "mode" and make nodes
"smarter" to avoid complexity, but I can think of several situations
where a simple multiplication of two inputs would create an output
that is, in practical terms, the same than a premultiplied image
without being one. It's impossible to predict what the compositing
artist will do, and as it has already been discussed both alpha modes
are needed across the composite.

Personally I don't think the compositor needs much improvement in that
regard since it already offers the tools to move from one alpha "mode"
to the other. And if the compositor needs something is making that
more visible rather than hiding it.
Assuming things you can't really assume is the problem. For instance,
we have a serious input/output problem in the compositor with with
gamma-corrected premultiplied images and color management.
Premultiplied images are being linearized without "un-premultiplying"
alpha and that creates an input that is not premultiplied or straight
and it's impossible to comp right (a tiff file, for instance, can have
premultiplied OR straight alpha. If it's premultiplied it's impossible
to comp it right in Blender).
A simple switch to manually declare if the input is premultiplied
(triggering an unpremul before linearization) would solve this problem
and help users to track the alpha "mode" across the composite. The
same goes for the outputs, before final gamma-correction.
IIRC Troy_s sent a patch for that, and if there isn't a better
solution available I'd say it should be used immediately, since the
current state is broken and there's no other solution than converting
manually all the external assets to unassociated alpha (and that
doesn't seem very consistent if the user chose "Premultiplied" to
render CG).

AFAIK, the rest of the alpha problems are simply mismatches between
what is expected and what is used. Blender apparently expects
premultiplied RGBA for most of the operations, so the best solution
seems to unify that and do the proper divisions when straight alpha is
needed, and of course make linearization of non-linear assets happen
before premultiplying images that have unassociated alpha, or
predivide>linearize>multiply when inputs are already premultiplied.
If source material doesn't declare how its alpha is stored and if
they're gamma-corrected or linear, the safest is to add selectors and
let users choose. The same goes for outputs.
If users are informed about what's expected in each case it would be
easy to make a decision. Other apps like Nuke seem to have adopted
that strategy and I think we should too.
The alternative is to make assumptions, and the Adobe Forums thread
shows what could happen with those assumptions if they're wrong.