Your image shows you having a rough average error of somewhere
between 0 and 13 on in most areas, and the worst case of banding seems to show a rough error of around 11 between two sections. At the top-end this is quite
significant, but reflects the fact that you’re using the fast
compressor. Could you post the original image so that I can look at this in greater detail? Errors in the fast compressor are somewhat expected, as this is really only designed for quick iteration during development. For deployment we recommend at least the normal compressor, so I’d like to look into the errors that come from that to see if anything can be improved.
Unfortunately the thing you mention about less RGB data being needed when alpha is present is not simply something that can be “turned off”. To encode RGBA data into the same number of bits as for RGB data, some RGB precision has to be lost to accomodate the extra channel, which is probably the reason you’re seeing the banding. The harder you allow the compressor to run, the better it will be able to hide this. I’m afraid that currently we have no plans to release our compressor as open source.
So, it appears that RGBA PVRTC special-cases blocks with 100% alpha so that they have good rgb-quality. But, if the block isn’t a==255 it is stuck with crappy rgb quality. This is great for blending textures. Unfortunately, it means that packing scalar parameters into the alpha channel isn’t really viable with PVRTC. More texture reads it is then. If this is a feature of the compressor, I’d be really happy to be able to turn it off. But, at this point I expect it’s a feature of the format.
I think the misunderstanding is that PVRTC is tied
to RGB or RGBA in a single texture. In actual fact, what most people
don't realise is that PVRTC can have a mix of RGB and RGBA blocks in a single
texture - they can exist side by side. So the "special cases" are
actually blocks without any alpha. The quality isn't tied to the "alpha
complexity", it's just that when a given area is opaque, the compressor
will simply not encode an alpha channel. This proves to be a simple and
highly effective optimisation.
As you've mentioned, the way this
works is great for blended textures, which is the majority of uses of
the alpha channel. Whilst PVRTC will try to pack something else in there
if it's provided, it is impossible to guarantee the exact same quality
between an opaque area and a transparent one, due to the lower amount of
One more follow-up for the benefit of anyone reading this. There is apparently another threshold when the alpha value is <= 8/255. The image below is the RGB of the result of compressing then decompressing RGBA pvrtc 4-bit, NORMAL quality. The RGB is a photoshop “clouds” render and the alpha has 4 (not 3) stripes of 255, 254, 9, and 8 descending. The background alpha is 0. Note that the RGB in areas with 0 or 8 alpha has turned completely black, but the stripe with 9 alpha is OK.
This was a problem with the compressor where it was forcing its own pre-process pass on near-transparent RGB data. This has been fixed in later versions of the compression code, hence you don’t see it in the tool version, and any new releases shouldn’t suffer this issue.
FYI this is actually a problem with the compressor - the rgb data was in fact wiped out, so you’d see this on device too.