Using the gui tool and the library 2.09.29.0649 I am seeing better quality in PVR4 compression with the tool.
I assumed CompressPVR would deliver the best quality by default.
The documentation even says:
choosing PVRTC (2bpp/4bpp) compression, suitable values are:
- 0 = Normal, high quality compression
- 1 = Fast, medium quality compression
Since 0 is default, “high quality”, I believe it to be the best.
But actually setting nMode to 1 delivers the same great quality as the gui has.
Now, is this a bug in reversed options or can it be for the high quality mode to be worse than the medium quality, and then can I assume the gui is medium quality?
Pierre2011-11-23 16:06:56
Hi Pierre,
Yes this is a problem with TexTool/TexLib, it's to maintain backwards compatibility - for some reason they have always been reversed in TexTool. At some point I plan to update the interfaces to both utilities, at which point I will unify the two options.
In the meantime, PVRTexLib's options progress from 0 to 3 in progressing quality. In PVRTexToolCL however, the options progress in the order 1,0,2,3 (1 is fast, medium quality, 0 is normal, 2 is higher quality, 3 is slowest, best quality). Options 2 and 3 in each are identical, but 1 and 0 are switched.
I'd also suggest you grab the latest PVRTexTool/TexLib from the utilities page as there is an update to the PVRTC 2bpp compressor which fixes some fairly nasty artifacts that show up during compression with "normal" compression.
Thanks,
Tobias.
Tobias2011-11-23 17:17:32
I must follow up on this.
You are saying using the Lib and CompressPVR to compress to PVR4 I can actually specify four quality levels? 0-3? Then the documentation is really out of data as it just refers to two options (as I wrote above).
Further, I am big fan of explain the functionality in the header file. This way the coder updates it and no one has to rely on some outdated documentation. Because in the header it tells you basically nothing what nMode does exactly, or expects.
Again: PVR4, 0=low quality, 3=highest?
Thank you.
Hi Pierre,
The documentation should have been updated - I’ll have a look into this because it should all be explained there. So yes, in the library, 0 = lowest, 3= highest.
Thanks,
Tobias
Hi Pierre,
I’ve just looked at the documentation, and you’re right, these have been missed off from the PVRTexLib documentation, and in fact are incorrect… I’ve filed a bug in our internal Bug Tracker (BRN35108) and it should be fixed shortly.
My suggestion to maintain clarity is to use the enums defined in PVRTexLibGlobals.h - there is an enum value for each of these modes (“E_PVRTC_ENCODING_MODE”) which will be continually maintained. Equally in PVRTexToolCL there are arguments -pvrtcfast/normal/high/best which should give more clarity and perform the same functionality.
Sorry about the confusion, and thank you for alerting us to this problem.
Regards,
Tobias
