Previously we were using the old(pvrtc v2) PVRTC Command Line to convert our TGA textures, but in the latest SDK 3 PVRTexTool has dropped support for TGA so we moved over to using PNGs.
We noticed the quality of the alpha was atrocious in the new version.
After playing around in the PVRTexTool it became apparent that the way PNGs are handled produces vastly inferior results.
I have discovered that using alpha bleed on the PNGs before processing does help, but the quality is still slightly worse.
It just seems strange to drop support for TGA textures for no obvious reason, when they produced the best results!
This image below illustrates the problems:
BTW you can still get TGAs into the newest PVRTexTool by dragging them in, they convert fine, but obviously they won’t open from the file menu or work with the CL.
Do you think you might re-implement TGA support in the future or improve the PNG support?
TGA support was initially dropped due to moving from the FOX Toolkit to Qt, and having some teething problems along the way. Previously we had just dropped the appropriate FOX modules into the command line, but with Qt we need to link dynamically. Having to move Qt libraries around with a command line module is clunky, so we created our own image loading library. However, formats we don’t support there are still supported by Qt, which is why the drag and drop works.
Regardless, TGA support is something that I’ve already committed to adding back in at some point, (hopefully by r3.2). Adding it to the GUI is trivial so that should be done shortly, as I can just use the Qt libraries. Adding support back to the command line though will take a little longer, but should be done in due course.
Out of interest, do you get the same results if you use PNG in the old version of PVRTexTool? I’m just wondering if this is entirely a PNG issue or if it’s because of a change in the compressor between versions. You could probably get around the problem by exporting your alpha channel to the r/g/b channel of a separate png file and loading it in using the channel editor functions for now.
Thanks for the response, glad to hear that you are committed to adding it back in.
Really we are only interested using the format that offers the best quality, if PNG got to that point we would use that.
PNGs have always had this issue even in the previous versions. It gets particularly bad on the lower MIP levels, that is why we have aways used TGA, and were quite shocked to see support for it dropped…
I have tried saving PNGs out from photoshop in a variety of ways (save for web etc) to see if that makes a difference but nothing changes. It just seems really strange, I would assume (form a lay perspective) that the raw data is pretty much the same between a uncompressed PNG and TGA…