[Bf-funboard] Alpha handling of Cycles material nodes: Proposal to switch to straight RGB values

[Brecht Van Lommel]

Hi,

It's not this simple. First, color sockets in cycles (and OSL and
blender internal) nodes have only RGB channels, no alpha, that's
separate. So in general the colors in the shading nodes are not
"premultiplied" or "straight", they're just colors without alpha.

For the image texture node, there are cases where you want to have
straight and premultiplied out, always using straight is not a
solution, and premultiplied alpha is not an optimization, it's really
about the way light works in reality and just a different concept.
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.66/Image_Transparency#Theory

If you have an image with alpha information, and you only want to use
the color channel to plug into e.g. a diffuse BSDF or emission shader,
then you actually want the image to be premultiplied, otherwise you
get ugly fringes. However if you are later mixing that node with a
transparent BSDF based on the alpha channel, then you want straight
alpha output, because otherwise the alpha would be multiplied in
twice.

So what the current code tries to do is make that work automatically
in most cases. I admit it's confusing, we could make a manual
straight/premultiplied switch, but then of course that means user will
have to learn about the differences and manually set this each time.
Maybe they do too now but with the automatic system they can not know
about it and still get correct results in most cases. It's one of the
disadvantages of this lower level shading node system, like the color
space that you have to set for normal maps which is a continuous
source of confusion.

I'm open to proposals for a better system, but unfortunately "always
use straight" is not a solution in my opinion.

Brecht.

On Sat, Jun 22, 2013 at 1:55 PM, Yu Asakusa <yu.asakusa at gmail.com> wrote:
> Hello,
>
> I propose to change the behavior of the Image Texture material node in
> Cycles so that the Color output is always straight (non-premultiplied)
> RGB values, possibly with a flag to retain the current behavior for
> backward compatibility.  Currently the Color output is straight RGB if
> anything is attached to the Alpha output socket, and premultiplied RGB
> otherwise, as explained in
> <http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Textures#Image_Texture>.
>  The same proposal applies also to the Environment Texture material
> node.
>
> (Aside: Blender 2.67b contains a bug which causes the Image Texture
> material to output a wrong color when the Open Shading Language is
> enabled <http://projects.blender.org/tracker/index.php?func=detail&aid=35812>,
> but this bug has been fixed in the development version.  Thanks to
> Brecht Van Lommel for fixing the bug.)
>
> The current behavior (ignoring the bug) violates a fundamental
> assumption on how nodes work: the information should flow from the
> input to the output in each node.  In particular, this assumption
> implies the output values of a node should be determined by the input
> values of the node, and should not be affected by how/whether these
> outputs are used.  My proposal recovers validity of this assumption.
>
> In addition, I fail to see the point of using premultiplied RGB values
> in Cycles material nodes in the first place, because BSDF shaders need
> straight RGB values anyway (see Brecht Van Lommel’s comment at
> 2013-04-05 12:44 on
> <http://projects.blender.org/tracker/?func=detail&aid=34679>).
>
> With my proposed change, Blender will use straight RGB values in
> Cycles material nodes, and premultiplied RGB values everywhere else,
> unless the user tells otherwise (e.g. by using the Alpha Convert node
> in the compositor).  This may sound confusing, and I admit it is not
> ideal to use different conventions in different parts of one program,
> but note that the current behavior is more confusing because the
> convention is not consistent even in one node.
>
> (I believe the *ideal* thing to do would be to switch to the straight
> RGB altogether and view premultiplied RGB just as an optimization
> technique used inside the code which should not be exposed to the user
> at all.  Because this ideal thing will not happen any time soon, I am
> proposing a compromised solution here.)
>
> Regards,
> Yu
> _______________________________________________
> Bf-funboard mailing list
> Bf-funboard at blender.org
> http://lists.blender.org/mailman/listinfo/bf-funboard