[Bf-committers] Color space and alpha issues
francoistarlier at gmail.com
Mon Dec 19 09:57:38 CET 2011
> 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.
That's exaclty what I was going for, regardless on how the data is managed
under the hood, an entire composition in premult or unpremult is just not
possible in so many cases. and doing the conversion manually is still in my
opinion the best way to manage it through your entire comp. Yet you have to
know what you are doing and when you need it.
The option per node in nuke is indeed for sure, but yet I prefer to use a
special node for it, so visually in your node setup you can see when a
conversion happen. Maybe just an old habit though :/.
I only recently discover the alpha converter node (which was probably there
for ages, I never knew it was the premult node) I have been trying it
quickly, but I wasn't sure it was behaving like it was supposed to though.
I had some weird artefact. Yet I had other problem with blender at that
time, so I'm not sure it was coming from this though
(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:
> > 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
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers