Alpha Premultiply broken in Blender exporter

Component:Blender Exporter
Category:bug report
Assigned:David Bluecame


povmaniac has reported that the Alpha Premultiply is "orphaned" in the current Blender Exporter.

Apparently some time ago it was decided to remove the premultiply option from the Blender Exporter, as apparently Blender requires the images with alpha to be premultiplied to be correctly displayed in Blender. See:


However there are some problems with the way that change was implemented:

* If the scene had "premultiply=off" set from a previous YafaRay version, there is no way to enable it in the Blender Exporter now, so the render to blender will have premultiply=off and give a wrong result.

* When exporting to file, the user may want to enable/disable the alpha premultiply for the output image. Now, it's not possible.


So, I'm thinking on fixing this and include this change along with the Color Spaces changes in the next beta. I'm thinking about doing these changes:

* When rendering into Blender, force the premultiply=on no matter how it's setup in the scene.

* When rendering into file/XML, show the premultiply option again so the users can choose what to do.


This also leads me to a question (that's why I marked this for review). When we process input textures with alpha, how are we supposed to treat the alpha and colors?

* RGB depending on the color space and Alpha as linear?

* RGB and Alpha as Color Space to be decoded to linear?

* RGB as premultiplied, so we have to pre-divide before rendering?

* If we have to "pre-divide", should we consider RGB as Color Space and the Alpha as linear for the division or how are we supposed to do it?


Too many questions, I know, but I would like to do the Color Spaces and Alpha right for good, if possible...



Premultiplication in render time is one hell of a obscure matter to me. I understand more or less when I read about it then a second later I can not figure out how it works and what it is useful for. But if you talk about it in a texture input context and mixing it with color spaces then my brains are about to explode. I really can't help you, besides how do you tell a texture input with alpha channel has been premultiplied? Besides I am not sure YafaRay can see alpha channels in texture inputs, it always ask for a second texture channel to map transparency.

PD: ok it sees transparency but as a map against the base color or another color texture channel.


Thinking about it, I believe it is safe to assume that alpha channels is just a scalar value from 0 to 1 and have nothing to do with space colors. Also premultiplication is just a 2D compositing technique used in sRGB enviroments. Ideally you would solve the compositing problem either before or after the linear space YafaRay works with.

For instance, you would solve the blending operation between a sRGB texture with premultiplied alpha against a base color or other sRGB textures first and then take the output result from the texture channels stack, which is still a sRGB value in a sRGB enviroment, to the linear space.


I agree, this gets complicated. As Color Space transforms are more or less defined for RGB, many of them are not defined for RGBA...

For example:

I'm thinking, perhaps the easiest and quickest would be:
* Force premultiply=on when exporting to Blender.
* Show the checkbox "Premultiply" again in the UI when exporting to file/XML so the user can choose how to export the render result.
* Remove the Alpha/Premultiply/Straight checkboxes and dropdown menus from the Texture panel, as YafaRay is ignoring them and they will only cause confusion to users.

Alternatively we could investigate more how to do this. For example, imagine that somebody uses as a texture a sRGB image with Alpha already premultiplied. Even if they don't use Transparency (or if they use Transparency from another texture), what is the "correct" way of processing that RGBA (alpha premultiplied) texture into a RGB image for the color texturing:
* Should we use it "as is" in the rendering?
* Should we try to reconstruct the original "Un-premultiplied" RGB values by dividing R/A, G/A and B/A?
* In the last case, should we convert the sRGB values to linear RGB first, for example R(sRGB) -> R(linear) -> R(linear) / A -> rendering ?
* Even more complicated, when using premultiplied Alpha we may need to decide if we consider the "matte" is black or white!! (??)

I thought the color spaces were difficult, but with Alpha my brain is also going to collapse!


A premultiplied texture is meant for a final blending operation, this is done against the object base color or another sRGB texture up in the stack. Blending mode Add finish the process and makes a more seamless integration between one and the other, particularly in the edges of the RGBA texture. The compositing operation is finished and when sampling the texture color, you don't need to carry on with premultiplied RGBA data into yafaray internals, even if you want to derive alpha data from that blending operation.

You can always decide when RGBA data is premultiplied or not as long as you track it when is premultiplied. However, as there will be precision loss for every premultiplication step, it is better do to it only when needed and not in every yafaray internal operation. YafaRay does not need premultiply to see one mesh through another. When the render outputs then you could decide again to premultiply or not for the Blender compositor or for XML output. 

That is why I think about solving the compositing problem premultipy poses either before or after yafaray inner linear space, though you can always carry alpha values internally but should be processed linearly all the time.


Status:needs review» ready to commit


After investigating Alpha Premultiply, I've decided to keep this matter as simple as possible, because Alpha Premultiply is a compex and non-standard issue with many possible scenarios depending on the file type and 3rd party software being used.

In any case, I've fixed the "broken" (orphaned) Alpha Premultiply option in Blender, forcing it to Premultiplied when exporting to Blender and showing a checkbox when exporting to file or to xml so the user can select whether he wants the output image to be premultiplied or not.

I've sent a pull request with these changes among the changes for Color Spaces:

I will try to prepare new Experimental builds with all these changes as soon as I can.


No problem David, users can make their 'alpha over' operations in an image editor before using the result as input in YafaRay.


Status:ready to commit» fixed

Fixed in YafaRay-E (Experimental) v1.0.0


For more information, see:


If you still have this issue with the new version please let us know.


Status:fixed» closed

Automatically closed -- issue fixed for 2 weeks with no activity.