[Bf-committers] Color Unpremultiply

Matt Ebb matt at mke3.net
Mon Feb 20 02:55:28 CET 2012


On Fri, Feb 17, 2012 at 8:04 PM, gespertino at gmail.com
<gespertino at gmail.com> wrote:
> First of all, the text in the tooltip is a little bit misleading. The
> operation performed isn't done to avoid a fringe on light backgrounds. It's
> done because colorspace conversions shouldn't be performed on premultiplied
> data.
> The resulting effect when doing it wrong is indeed a fringe, but what the
> operation does is to deliver a properly converted image, not avoiding a
> fringe.
> This may sound silly, but I think that using a more accurate tooltip would
> have an educational effect because people would know what it does or would
> investigate more rather than "this is for reducing a fringe".
> A fringe can come from a wrong compositing earlier, and believing that
> color unpremultiply will fix it is wrong.

+1, correct

> Apart from that, I wonder if it's really necessary to have that option
> instead of just applying it whenever premultiplied alpha is selected and
> the output file is gamma-corrected.

Eh? I presume you're talking about the render option that does this at
the end of the pipeline before saving imagery out of the
renderer/compositor, and not the option per image that does this when
loading the image, right?

The Sky/Premul/Straight options are purely blender internal renderer
things, they don't have any bearing on what comes out of the
compositor. You can un-premultiply a transparent image in the
compositor and pipe it straight to the output if you like, and while
it will look bad in the viewer, it is a valid thing to do if you
really want to. In this case, you don't want another divide before
colour space conversion and need the option, no matter what
sky/premul/straight option is set for BI.

For situations where you're just rendering through BI straight to disk
with no compositor, and the system knows it's Premul, you may have a
point. But afaics that's not how this option works - it's a bit
misleading having this option in the shading panel, which is full of
BI related properties, since this is something that happens at the end
of blender's entire imaging pipeline. If you want to make things
clearer, perhaps the option should be on the compositor output node
itself, and when you're not using the compositor, rendering straight
out of BI, it could just do the right thing automatically since it has
all the information to make that decision itself. Much of a muchness
really, though...


More information about the Bf-committers mailing list