Hi,
I would like to have support for a premultiplied alpha blending mode in
SDL_RenderCopy.
Would this be feasible to add to SDL2?
The rationale is that premultiplied alpha allows “correct” bilinear
interpolation when scaling without having to do alpha weighting (which
hardware scalers don’t). I am needing this for OSD rendering in mpv.
In OpenGL, this is achieved by setting the blend function to GL_ONE,
GL_ONE_MINUS_SRC_ALPHA (as opposed to blending with separate alpha, with
is GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA).
Best regards,
Rudolf Polzer
+1 to this suggestion.
And yeah, premultiplied alpha is a hack to a hack. Normal alpha
blending works just fine, the problem is that texture filtering
creates colors that shouldn’t be there for starters which is why this
is needed 
Also it could be possible to allow textures to be converted to
premultiplied alpha on the fly (when the texel data is loaded into
them), but that’s probably something the program could do on its own
without that much effort (the only advantage would be avoid having to
write that code every time you make a program).
2012/12/11 Rudolf Polzer :> Hi,
I would like to have support for a premultiplied alpha blending mode in
SDL_RenderCopy.
Would this be feasible to add to SDL2?
The rationale is that premultiplied alpha allows “correct” bilinear
interpolation when scaling without having to do alpha weighting (which
hardware scalers don’t). I am needing this for OSD rendering in mpv.
In OpenGL, this is achieved by setting the blend function to GL_ONE,
GL_ONE_MINUS_SRC_ALPHA (as opposed to blending with separate alpha, with
is GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA).
Best regards,
Rudolf Polzer
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
The rationale is that premultiplied alpha allows “correct” bilinear
interpolation when scaling without having to do alpha weighting (which
hardware scalers don’t). I am needing this for OSD rendering in mpv.
Sounds interesting. Do you have a link that explains this more? What’s
wrong with good old mipmapping?On 11 December 2012 16:32, Rudolf Polzer wrote:
This explains the practice a bit more:
http://home.comcast.net/~tom_forsyth/blog.wiki.html#[[Premultiplied%20alpha]]
I’m going to disagree with the sentiment that premultiplied alpha is a
hack. It’s actually the right way to do things - it’s closer to how
light physically behaves, and it makes a ton of different image
operations work out nicely.
Anyway, just my 2 cents. Would be nice to have premultiplied alpha support.On Tue, Dec 11, 2012 at 9:48 PM, Robin Kaup <k.robin64 at gmail.com> wrote:
On 11 December 2012 16:32, Rudolf Polzer wrote:
The rationale is that premultiplied alpha allows “correct” bilinear
interpolation when scaling without having to do alpha weighting (which
hardware scalers don’t). I am needing this for OSD rendering in mpv.
Sounds interesting. Do you have a link that explains this more? What’s wrong
with good old mipmapping?
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Technically premulitplied alpha and normal blending both lead to
exactly the same calculation. The problem is that in the latter
texture filtering gets in the way, so premultiplied alpha is used to
work around it (it changes in which step texture filtering happens).
The real hack here is texture filtering, but there’s no way around it.
There are other reasons to go with premultiplied alpha too anyway
(half the amount of multiplications, and you can use it for both
translucency and additive blending).
2012/12/12 Michael Henning :> This explains the practice a bit more:
http://home.comcast.net/~tom_forsyth/blog.wiki.html#[[Premultiplied%20alpha]]
I’m going to disagree with the sentiment that premultiplied alpha is a
hack. It’s actually the right way to do things - it’s closer to how
light physically behaves, and it makes a ton of different image
operations work out nicely.
Anyway, just my 2 cents. Would be nice to have premultiplied alpha support.
On Tue, Dec 11, 2012 at 9:48 PM, Robin Kaup <k.robin64 at gmail.com> wrote:
On 11 December 2012 16:32, Rudolf Polzer wrote:
The rationale is that premultiplied alpha allows “correct” bilinear
interpolation when scaling without having to do alpha weighting (which
hardware scalers don’t). I am needing this for OSD rendering in mpv.
Sounds interesting. Do you have a link that explains this more? What’s wrong
with good old mipmapping?
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Technically premulitplied alpha and normal blending both lead to
exactly the same calculation. The problem is that in the latter
texture filtering gets in the way, so premultiplied alpha is used to
work around it (it changes in which step texture filtering happens).
Correct. In my case though, the input is already premultiplied anyway, and I would have to divide to get regular blending.
The real hack here is texture filtering, but there’s no way around it.
Well, the filtering COULD use alpha weighting… Not impossible in GLSL. But it is quite likely a lot faster to use the filtering provided by OpenGL, which is not alpha weighted.
There are other reasons to go with premultiplied alpha too anyway
(half the amount of multiplications, and you can use it for both
translucency and additive blending).
And you can combine multiple transparent renders to one render target you then can e.g. fade out - useful for GUI effects.
Note also that opaque, blend, add and “modulate with grey” can be all done as premultiplied alpha render, cutting down on GPU state changes.
Best regards,
Rudolf PolzerAm 12.12.2012 um 04:12 schrieb Sik the hedgehog <sik.the.hedgehog at gmail.com>: