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

[Yu Asakusa]

Hi Brecht,

> First, color sockets in cycles (and OSL and
> blender internal) nodes have only RGB channels, no alpha, that's
> separate.

I know.  That is exactly why we should not use premultiplied in
material nodes: it is not well-defined without alpha channel.

> 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.

I do not think this is true.

The Diffuse BSDF node expects diffuse color as input, and feeding the
premultiplied RGB to a diffuse BSDF node simply means that you are
assuming the transparent part should be interpreted as black.  If you
put an object in black background, that may give a fringe-less result,
but if you put the same object in white background, it gives ugly
fringes, unless I am mistaken what you mean by ugly fringes.  If you
want to treat alpha as alpha, just using the Diffuse BSDF node cannot
give you the correct result; you have to use transparency of some kind
anyway.

It makes sense to feed premultipled RGB to an Emission node.  However,
note that an Emission node already accepts color and strength.
Feeding the premultipled RGB as the color and 1.0 as the strength is
just a shortcut for feeding the straight RGB as the color and the
alpha as the strength.  In my opinion, violating the general principle
of how nodes work just for this ad hoc shortcut is not a good
tradeoff.

Regards,
Yu

On Sat, Jun 22, 2013 at 8:49 AM, Brecht Van Lommel
<brechtvanlommel at pandora.be> wrote:
> 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
> _______________________________________________
> Bf-funboard mailing list
> Bf-funboard at blender.org
> http://lists.blender.org/mailman/listinfo/bf-funboard