I am using PVRTexLib to compress some textures to PVRTC4. As part of the process, I am also using the library to premultiply RGB by Alpha and to generate mipmaps. When I view the textures in-game with blend mode “1, 1-srcAlpha” there are clearly leaks of RGB from the solid areas into areas that should be [0,0,0,0]. The Alpha in the leaks is correctly 0. Combined together, this is causing additive artifacts on the edges of the solid areas. These artifacts do not occur when I use 8888 or 4444 formats.
Is there a recommended way to set up premultiplied alpha with PVRTC?
When PVRTC (-I) was designed back in 2000/2001, it was normal practice for applications/games to use non-premultiplied** alpha and, thus, when the special "fully transparent"/punch-through code is used for a pixel it, more or less, uses a mix of the neighbouring colours for the RGB components instead of pure black. Using this blended RGB then reduced haloing that otherwise occurred.
Unless there is a way to disable use of "punch-through" in the compressor library (but unfortunately I can't see that such a flag is exposed in PVRTexLib.h), it may be that your only option is to revert to non-premultiplied for these textures.
Simon
**I guess the fact that premultiplied alpha had been shown to be better had simply been forgotten by much of the industry - myself included.
Unfortunately this functionality hasn’t been exposed in PVRTexLib so you may have to just revert back to un-multiplied textures as Simon has suggested. There are plans for PVRTexLib to allow greater control over the compressors via some sort of setting functionality, and I will make a note of this as a feature to be added.
The only other thing I can think of, I believe that the compression code doesn’t allow punch through alpha if you’re using 2bpp mode, so you could try using PVRTC2bpp, if you can get suitable results from this I believe it could alleviate your problem of pre-multiplying alpha?
Thanks,
Tobias
Bumping this feature request. I am working on an Android app where an OGL window is overlaid on top of a another window. In the Android GUI system, overlays are hard-coded to premul alpha compositing. I can work around the data issue by premultiplying in the shader. But, this affects a lot of pixels in the OGL GUI and has a measurable effect on frame rate compared to just “gl_FragColor = texture2D(…)”.
Hi Corysama,
I've had a look into this for the next release, but it seems that there's not
really much that can be done with PVRTC-I to alleviate this. Despite recent
improvements in the compressor, the format was sadly never designed for UI
elements. The situation is far better with the new compressor, so compressing
to 4bpp with the highest quality compression could be enough for you - but
there is still some bleeding.
So my suggestion unfortunately has to be to use a 4444 format for any textures
that use alpha, and PVRTC-I for any that don't. Try the new compressor though
(There’s an updated version of PVRTexTool/Lib available now, we’re going to
make an announcement later – I’m just jumping the gun a bit :)),
it's much better in these situations than the last release, so your textures
may work well enough with it to be viable.
Thanks,
Tobias
Tobias2011-10-20 11:09:53
That new version very well timed! I’m in the middle of working on our texture pipeline as we speak. And, do I see a static-linked lib for Windows? Wonderful!
At this point, the only thing I could wish for would be compression with more speed, more speed, more quality and more speed! 
Thanks, Tobias!
