Sorry to hijack your topic, but i was looking into a way to make ktx2 conversion part of the Blender exporter. All i had seen was C based code.
While i had previously made a DLL for Blender to directly connect a Kinect 2 motion capture device, that seems inferior to a Python based system. Where did you get it?
Just something we wrote. Not a blender plugin or anything, part of a larger texture conversion system that takes in pngs and spits out a variety of image formats in different LODs.
The current code for the MSC transcoder module needs that supercompressionGlobalData have non empty data to work in the ETC1S case. I will have to see if we can do something about it.
It seems that not specifying an encoding scheme with ktxsc will generate a ETC1S encoded file. But Zstandard compression (--zcmp) is not supported for ETC1S. Excerpt from ktxsc -h:
--zcmp [<compressionLevel>]
Supercompress the data with Zstandard. Implies --t2. Can be used
with data in any format except ETC1S / BasisLZ. Most
effective with RDO-conditioned UASTC or uncompressed formats. The
optional compressionLevel range is 1 - 22 and the default is 3.
Lower values=faster but give less compression. Values above 20
should be used with caution as they require more memory.
So, you should either use UASTC if you want to compress with Zstandard, or select the ETC1S compression scheme:
This was it!! Quick question on the compressionLevel. Is “speed” affect the speed of de-compression at runtime? or only the speed of the conversion to initially compress it. Because we dont care about the speed of compression, but we absolutely care about decompression.
Also for anyone coming along with same problem, we were able to change back to RGB instead of RGBA and have it still work. Was just the ESTC1S vs UASTC