Clear PVRTC

[mikiex]

Maybe Simon wants to speculate (or explain if he knows) what method they are using to encode these.
Though I haven't tested it, so I can't say for certain how good the results are compared to pvrtextool, it does look interesting.
http://www.webtech.co.jp/eng/imesta/smartdev/detail.html

Back in the day the Optpix imagestudio by the same people had very nice palette reduction (maybe not important here but they have a good history of getting the most out of an image)

 

[Simon F]

It's a bit hard to tell without access to the original source texture, but I've found one problem with these sort of 'sprite' textures is that the developers sometimes completely ignore what is in the fully transparent regions. A case of "out of sight, out of mind".

The compressor, OTOH, can't ignore what's in these regions because it doesn't know how the developers are going to use the texture. The blend mode can be critical and some developers don't even use the alpha channel for transparency.

If the colours in the transparent regions are doing "interesting" things, the compressor will do its best to represent those changes and that usually means something else will be compromised. If I get a chance I'll try to post an example, but some I've seen have had random spots or noise, or transitions between contrasting colours (white->black or magenta).

Further, PVRTC1 4bpp has a preference for non-premultiplied blends and assumes that the colours in the translucent regions are not dissimilar to their more visible immediate neighbours.

As for Clear PVRTC, it may be that they are forcibly applying a filter to the input data to remove strange colour behaviour in the transparent regions. (FWIW there is a simple, optional pre-processor in PVRTextool which can help with these issues).

 

[Simon F]

One thing I did find interesting on their page (http://www.webtech.co.jp/eng/imesta/smartdev/detail.html#OS003) was the PNG optimiser example that replaced the 24bpp PNG with a palettised 8bpp: i.e:

....becomes....

.
This shrinks the image from 63k PNG to 21k but only with respect to application size. When loaded it'd jump back up to approx 125k.

If, however, you were to use 4bpp PVRTC (or better still, PVRTC2), the size (without additional compression) would be around 16k, would still be 16k when loaded, and the quality seems better.