I'm want to use the PVRTexTool CLI (ver. 3.11, SDK Build: 2.06.26.0619) to compress a bunch of PNGs to the ETC1 format and save the compressed image as a .ktx file. The command I used is as follows:
The compressed file is saved but in the wrong format (the saved file always seems to have the PVR format).
Executing "PVRTexTool.exe -help" says: "-o Output filename. Extension will depend on the mode chosen by options -p, -dds, -h etc." and the manual doesn't have any additional relevant information either.
Is there anyway to override this behaviour and have the tool put the compressed texture in a file format of my choice (KTX in this case)?
Note: I'm able to save to KTX format via the GUI version of the tool (File-> Save As.. and select "Khronos texture files (*.ktx)" in the "Save as Type" dropdown) and open this file via another program that supports the KTX format.
Edit: Tried this with ver. 3.30 SDK Build 2.10@839873 , behaviour is the same (CLI can't export to KTX where as the GUI can).
I have just had a look into this and it appears that saving to ktx has never been supported in the command line tool. It's a feature that nobody's asked for until now which is why I'm guessing is why nobody has noticed! I assumed it was there and this was just a minor bug but there's actually no way to do this at the moment I'm afraid. I'll certainly make sure it makes it into the next release. Are you able to work around this limitation, or is this going to be a blocking issue for you?
I'm afraid that this is pretty much a blocker for me since the CLI version of the tool is invoked as a part of the build to batch compress textures to the desired format.
What are your thoughts on these alternatives:
Is it be possible to use PVRTex or another tool to convert the PVR files to KTX? I could add additional step to the build scripts as a workaround.
Is there a way to invoke the GUI version of the tool via the command-line or (or to control it programmatically through other means)?
Wait it out for the next release. When is the next release is expected? (least desirable option)
Also, any other alternatives/suggestions to work around this problem would be appreciated.
Edit: I've already tried Ericsson's etcpack, but unfortunately, since it supports only the ppm format for input images and does not support mip-map generation its not of much use. The images that I want to compress are mostly PNGs. So, using etcpack would mean an a 3-step compression process: PNG -> PPM -> KTX and even more steps for compressing images for all mip-map levels.
One option available to you could be to use PVRTexLib instead of PVRTexTool, integrating the library directly into your tools and compressing this way. It might make sense but depends on your pipeline really. Would this be a viable option for you at all?
To use PVRTexLib would require creation of a "wrapper" program for all platforms and invoking it instead of the PVRTexTool.exe. This is a possible approach, but I'd like to avoid this if possible, since this approach represents (relatively) high time/effort for an interim fix till the next release.
When the fix is ready, would it be possible for you to provide 32-bit binaries (all platforms) through this forum? I'd really appreciate it. If this isn't possible then I'd have to fall back to the wrapper-program solution.
I’ll try to get this fixed, but our command line is due for an overhaul; it’s original limited purpose use is holding it back somewhat and making it difficult to add new features without breaking old ones. This consequence of this is that it might take a bit of time to get it done unfortunately. Once I get it into the current version I’ll post an update to the website and let you know.
I’ve managed to get this update into the latest version of the tool (use -ktx). This version is now available from the website. Let me know if you have any issues.
is able to generate a ktx file. However, there is now a new problem. I'm unable to open the generated .ktx file with GUI version of PVRTexTool (from the same build as above). I've also tried to open this file with other editor/viewers, but none of them are unable to open it. One other thing is that the size of the compressed file produced by PVRTexTool (43kB) is larger than the source file (35kB), which is quite surprising. The same input file when supplied to etcpack, results in a smaller file (33kB).
Is all of this expected behaviour? Also, are there any alternative tools/programs for viewing the compress .ktx
image (this is to visually ensure that the compressed image is
acceptable).
That’s strange, I tested and fixed that issue for the previous build… I wonder if something has regressed? Are you using up to date versions of both the GUI and the CL utility?
The difference in size is likely to happen with PNGs due to differing compression schemes - PNG will compress as far as possible, whereas texture compression has to do a fixed rate compression. A PNG could compress a 512x512 image of a single colour into a very small file, whereas ETC would have to still allocate 8 bits for every pixel.
The difference in size between PVRTexTool and ETCPack is simply that PVRTexTool generates MIP Maps by default, whereas ETCPack doesn’t, at least this is my understanding. Could you send the ktx file generated to devtech@imgtec.com and I’ll take a look at it?
Are you using up to date versions of both the GUI and the CL utility?
Yes. I'm using "Build: 2.10.90.5358" which is the latest available software on this website. Am I required to obtain the software from some other location?
Tobias wrote:
Could you send the ktx file generated to devtech@imgtec.com and I'll take a look at it?
I've sent an e-mail with the subject "KTX Compression Issue". Since I cannot share the actual image that I'm trying to compress to ETC, I've attached a public domain image instead (which also produces an un-openable .ktx file).
As far as I can tell I’ve solved the issue - it was ETC specific, everything else should work without a problem. It was down to choosing the output format from a list of OGL formats rather than ES formats. ETC isn’t supported in OGL hence the issue.
I’ve fixed this in the code, and will get a fresh release to the website soon.
PVRTexTool is currently capable of outputting non-ETC textures to KTX already - it is only ETC that is blocking currently, is this the issue you’re having?
The next full release of our SDK will have this fix which is coming up in a couple of months - we’re quite far into it now so we’re not going to post a new version of the tool to the website until this point now.
If this is going to be an issue for you going forward, please email devtech@imgtec.com and I might be able to help you a bit more.
Thanks,
Tobias
PS. Bhargav, if this is a blocking issue for you as well, also feel free to email.
Yes, ETC output in .ktx format is the one I’m missing. However, it seems that the ATI Compressonator is able to output ETC1 files in .dds format which I can then convert with another tool to .ktx as a workaround. So consider it a nice-to-have feature right now.
PS. Bhargav, if this is a blocking issue for you as well, also feel free to email.
This is an important feature for me. It would be really helpful if you could provide a beta-version of the tool with the fix for this.
elias.naur wrote:
However, it seems that the ATI Compressonator is able to output ETC1
files in .dds format which I can then convert with another tool to .ktx
as a workaround. So consider it a nice-to-have feature right now.
This is a possible work around for me as well, thanks for sharing.
