Should "convert premultiplied" be enabled when using "alpha over" with render layers?
Raytracing engines are only capable of generating The One True alpha, associated alpha. However, encoding to file formats may have an impact on how the alpha is encoded.

It makes sense when one stops to realize that alpha represents a degree of occlusion at the spatial “pixel” geometry level. That is, it is useful to think of the pixel window as a rasterization of geometry. How much of the window does a portion of the geometry cover? What is the emission value? How occluding is the geometry? Can we model high emission with no occlusion such as the case of flares, glares, fires, glows, etc.?

Only associated alpha is capable of modelling this duality of emission and occlusion. Therefore, “Convert Premul” should rarely be used, and used with caution and informed application[1].

[1] Historically, Blender has long suffered from alpha issues that continue to this day. The Viewer window, for example, still continues to have alpha problems when compositing against a fully transparent background. Always test your composites against a temporary solid colour to avoid the problems with the Viewer. PNGs, being strictly unassociated, used to require the “Convert Premul” toggle in the compositor, but I believe this has been rectified and the alpha is converted in the compositor. TIFFs should be associated alpha in their alpha plane, with an optional TIFF tag for unassociated. Blender incorrectly interpreted alpha in TIFFs as of testing a year ago. EXRs store associated alpha representations of the render buffers, and are by far the best file encoding within Blender.

Further information:


Why should I never ever use &quot;Convert Premul&quot; on Cycles renders?