- March 26, 2012 at 9:29 am #30791
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:
PVRTexTool.exe -fETC -iC:Test.png -oC:Test.ktx -m -yflip1
… and the output is this:
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).
bhargavbhat 2012-03-26 12:08:43March 26, 2012 at 4:14 pm #35599
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?
Tobias2012-03-26 16:15:17March 27, 2012 at 3:53 am #35600
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.
bhargavbhat2012-03-27 04:22:43March 27, 2012 at 11:06 am #35601
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?
Tobias2012-03-27 11:06:36March 29, 2012 at 5:25 am #35602
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.
bhargavbhat2012-03-29 05:37:10March 29, 2012 at 12:07 pm #35603
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.
TobiasMarch 29, 2012 at 12:39 pm #35604
That would be great, thanks a lot.
I’ll put this change on a hold for sometime on my end and proceed after you’ve posted the update.
BhargavApril 24, 2012 at 8:43 am #35605
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.
TobiasMay 29, 2012 at 5:33 am #35606
With the latest version available from the website labelled “PVRTexTool (Build: 220.127.116.1158)”, the command:
PVRTexTool.exe -fETC -ktx -iTest.png -oTest.ktx -m -yflip1
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
bhargavbhat2012-05-29 06:59:43May 29, 2012 at 10:17 am #35607
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 512×512 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 email@example.com and I’ll take a look at it?
TobiasMay 29, 2012 at 10:47 am #35608Tobias wrote:Are you using up to date versions of both the GUI and the CL utility?
Yes. I’m using “Build: 18.104.22.16858” 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 firstname.lastname@example.org 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).
BhargavJune 1, 2012 at 2:42 pm #35609
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.
TobiasJune 17, 2012 at 1:24 am #35610
I’m also blocked by this issue since I need a ktx-capable PVRTexTool – when is the next release due?– eliasJune 19, 2012 at 10:25 am #35611
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 email@example.com and I might be able to help you a bit more.
PS. Bhargav, if this is a blocking issue for you as well, also feel free to email.June 19, 2012 at 10:27 am #35612
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.– elias