Explain how premultiplied alpha works

Question

Can somebody please explain why rendering with premultiplied alpha (and corrected blending function) looks differently than "normal" alpha when, mathematically speaking, those are the same?

I've looked into this post for understanding of premultiplied alpha:

http://blogs.msdn.com/b/shawnhar/archive/2009/11/06/premultiplied-alpha.aspx

The author also said that the end computation is the same:

"Look at the blend equations for conventional vs. premultiplied alpha. If you substitute this color format conversion into the premultiplied blend function, you get the conventional blend function, so either way produces the same end result. The difference is that premultiplied alpha applies the (source.rgb * source.a) computation as a preprocess rather than inside the blending hardware."

Am I missing something? Why is the result different then?

neshone

Answer 1

The difference is in filtering.

Imagine that you have a texture with just two pixels and you are sampling it exactly in the middle between the two pixels. Also assume linear filtering.

Schematically:
R|G|B|A + R|G|B|A = R|G|B|A
non-premultiplied:
1|0|0|1 + 0|1|0|0 = 0.5|0.5|0|0.5
premultiplied:
1|0|0|1 + 0|0|0|0 = 0.5|0|0|0.5

Notice the difference in green channel. Filtering premultiplied alpha produces correct results.

Note that all this has nothing to do with blending.

Answer 2

This is a guess, because there is not enough information yet to figure it out.

It should be the same. One common way of getting a different value is to use a different Gamma correction method between the premultiply and the rendering step.

I am going to guess that one of your stages, either the blending, or the premultiplying stage is being done with a different gamma value. If you generate your premultiplied textures with a tool like DirectXTex texconv and use the default srgb option for premultiplying alpha, then your sampler needs to be an _SRGB format and your render target should be _SRGB as well. If you are treating them linearly then you may not be able to render to an _SRGB target or sample the texture with gamma correction, even if you are doing the premultiply in the same shader that samples (depending on 3D API and render target setup differences). Doing so will cause the alpha to be significantly different between the two methods in the midtones.

See: The Importance of Being Linear.

If you are generating the alpha in Photoshop then you should know a couple things. Photoshop does not save alpha in linear OR sRGB format. It saves it as a Gamma value about half way between linear and sRGB. If you premultiply in Photoshop it will compute the premultiply correctly but save the result with the wrong ramp. If you generate a normal alpha then sample it as sRGB or LINEAR in your 3d API it will be close but will not match the values Photoshop shows in either case.

For a more in depth reply the information we would need would be.

• What 3d API are you using.
• How are your textures generated and sampled
• When and how are you premultiplying the alpha.
• and preferably a code or shader example that shows the error.

Answer 3

I was researching why one would use Pre vs non-Pre and found this interesting info from Nvidia

https://developer.nvidia.com/content/alpha-blending-pre-or-not-pre

It seems that their specific case has more precision when using Pre, over Post-Alpha.

I also read (I believe on here but cannot find it), that doing pre-alpha (which is multiplying Alpha to each RGB value), you will save time. I still need to find out if that's true or not, but there seems to be a reason why pre-alpha is preferred.