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

[Brecht Van Lommel]

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

The problem is that if you have an image with alpha, the right way to
do mipmapping and texture filtering is with premultiplied alpha.
Otherwise you get fringing at borders. Once the image has been
premultiplied however, it's impossible to recover the straight RGB
from the zero alpha regions, so if you want to use just the RGB
without alpha then, you get this ugly sharp transition from alpha 0.01
areas to 0.0. By compositing over a black background we avoid that
issue even though it may not give the result you wanted.

If you have a straight RGB and you really want just the RGB channels
and ignore the alpha completely, that has to be something that is
taking into account when loading the image. As we use OpenImageIO's
texture caching system, that's something we would need to implement
there so it's not simple to solve in Cycles.

But there is a reason why that isn't something I'm keen to do, and
that's that we will want to start using mipmapped/tiled .tx files for
rendering scenes bigger than can fit in memory. As those files already
contain mipmaps that means you'd have to decide this already at file
saving, or save two files with alpha applied and one without, doubling
disk space and sometimes memory usage.

If you have alpha in your file, Cycles will always use it in some way.
If you don't want that you should save a file without alpha.

Brecht.