[Bf-committers] Color space and alpha issues

[Matt Ebb]

Here's a few more thoughts:

I agree that in terms of data storage for final imagery, premultiplied can
be more flexible - eg. representing transparent, but emissive colours,
which can potentially be useful for things like emissive volumetric
elements. Personally I haven't run up against too many use cases for this
myself, it's hard to know how big of an issue this is. It's also
potentially possible to do this kind of thing with extra AOVs too...

That infamous Adobe thread has interesting background info in there, but I
think it's a little bit of a red herring for this issue in Blender - it's
more focused on specific behaviour that Photoshop has when loading EXRs,
rather than the merits of premultiplied vs unassociated alpha. There are
alternative EXR plugins for Photoshop that work better, keep the alpha
channel separate from colour info as an additional channel or layer mask
rather than trashing RGB info where alpha is 0.

>From my own personal experience in recent versions of Blender's compositor,
premultiplication is a real pain in the butt. It makes it very difficult to
do things to the colour independently, like colour corrections, filtering,
or manipulating the alpha channel independently with blurs, erosions,
etc. Several of the nodes like defocus and vector blur seem to require
premultiplied input and it's very frustrating to have any colour
information that may have been masked away, thrown away out of necessity.
Trying to work around this leads to more complexity and dodgy behaviour.

The issue with compositing is that the image buffers are not just used for
final storage and distribution, but they're used as a work-in-progress
scratch pad, and it's often that the way you work with channels doesn't
always represent something logical (eg. keeping masked out RGB pixels
around so you can retrieve them later).

The advice I got from the comp lead on my previous project was that his
recommended convention for working in Nuke with premultiplied inputs was
always to manually un-premult before any colour/filtering operations and
premult back again at the end of that chain before over-ing with other
imagery. Most nodes in Nuke have options on them to automatically premult
and un-premult before and after that node's operation, which is handy,
though if you've got a few corrections in sequence it makes more sense to
just do it once at the start and end of that particular chain.

This is bearable, though a bit cumbersome and sometimes easy to forget
since sometimes the effects of this are more subtle and don't leap out as
being obviously bad, even if they are incorrect. And I don't think this
recommended convention was always adhered to (people not being aware of
this/new starters/communication difficulties/etc) - I remember opening up
comps from other artists in various departments who weren't doing this.

With this in mind, at least for the compositor, I'm sympathetic to the idea
of making the correct behaviour the simplest, and default, especially in
Blender when there is probably a smaller proportion of imaging experts who
understand this well in the userbase.

cheers

Matt


(PS. I really recommend dropping the term 'key alpha'! That word has way
too much confusing/conflicting usage already, especially in blender)



On Mon, Dec 19, 2011 at 8:41 AM, Brecht Van Lommel <
brechtvanlommel at pandora.be> wrote:

> Hi,
>
> You also linked to this post here, which makes a point that I didn't
> fully get yet:
>
> http://groups.google.com/group/ocio-dev/browse_thread/thread/65e84a85416a8637/962ea485d1a210a3?lnk=gst&q=thoughts+on+alpha#962ea485d1a210a3
>
> There is actually no right way to do color space conversion on images
> with alpha, it depends on the background that they were or will be
> composited over. For color correction operations it's similar, to make
> it behave like painting applications it should work on key alpha, but
> this isn't necessarily "right".
>
> So perhaps there's still toggles needed to control if these operations
> should happen on premul/key alpha (for image load/save, and for color
> correction nodes).
>
> Brecht.
>
> On Sun, Dec 18, 2011 at 8:28 PM, Troy Sobotka <troy.sobotka at gmail.com>
> wrote:
> > I thought I'd add the "infamous" thread over at Adobe here regarding
> > associated versus unassociated alpha in the context of a system that
> > needs to support various formats.
> >
> > In this case, for those unfamiliar, this was the thread in which Adobe
> > responded to their (mis) handling of the EXR format.
> >
> > The players here are:
> >
> > Zap Andersson - seasoned image professional now with Autodesk.
> > Florian Kainz - architect of the EXR specification.
> > Chris Cox - veteran architect at Adobe.
> >
> > http://forums.adobe.com/thread/369637
> >
> > TL;DR version:
> >
> > Unassociated alpha systems cannot adequately deal with the inherent
> > specifics of associated alpha systems.
> >
> > I've also added a "Further Reading" section to Brecht's page.
> >
> > Hope someone finds it insightful,
> > TJS
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>