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

[Yu Asakusa]

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