KTX-Software
KTX-Software copied to clipboard
KhronosGroup
Fully support DDS to KTX2 pipeline
We should provide a straightforward and well-supported way of producing KTX2 files from DDS. An official open-source DDS implementation is here.
Yes, DDS to KTX and KTX2 would be great. Does anyone know which tool can do this conversion? I've been looking for it
We (three.js) are interested in these workflows as well. OpenImageIO might be part of the solution — it can read:
bmp, cineon, dds, dpx, ffmpeg, fits, gif, hdr, heif, ico, iff, jpeg, null, openexr, png, pnm, psd, raw, rla, sgi, socket, softimage, targa, tiff, webp, zfile
However, we've found OIIO's support for compressed DDS files and cubemaps to be ... less than complete (https://github.com/mrdoob/three.js/issues/24189). But at least OIIO may be able to convert some DDS files to PNG or OpenEXR, which KTX-Software could then ingest.
If there are any other possibilities, we'd be glad to hear about them, and to stop maintaining support for DDS and PVR texture containers in favor of KTX2. 🙏
I have tried modifying toktx to use OpenImageIO for reading images. The large numbers of dependencies it has is proving intractable. I have had many issues getting all these packages to build via vcpkg (the only package manager I've found that supports what might be termed redistributable packages) for all the platforms we are supporting. Furthermore building the packages for a single platform in CI, when the builds work, takes 45 minutes or more. Because of these issues I've all but given up on OIIO. I hadn't got far enough to actually try any DDS files.
I had a brief discussion with the primary maintainer of OIIO and it isn't clear that OIIO's DDS reader lets the caller retrieve unmodified, still compressed (raw) image data. The OIIO API model is different. A reader would need special features to provide access to raw image data.
It probably would be relatively straightforward to integrate just a DDS reader into toktx but import would be subject to whatever issues said reader has. If someone wishes to give this a try, contact me first to discuss. Before adding any more readers the way image reading is currently handled in toktx needs restructuring to ease adding new input formats.
Because of these issues I've all but given up on OIIO. I hadn't got far enough to actually try any DDS files.
Yeah, I didn't meant to imply OIIO should be integrated into KTX-Software. Keeping dependencies light makes sense to me. More that (1) it'd be great to see OIIO with a KTX2 plugin someday, and (2) users can potentially use OIIO to convert files to something like OpenEXR, then use KTX-Software to convert to KTX2.
...it isn't clear that OIIO's DDS reader lets the caller retrieve unmodified, still compressed (raw) image data. The OIIO API model is different.
That's a useful point. I'd be happy enough to see OIIO support something like DDS → RGBA32 (via OpenEXR or KTX2), then at least there is a lossless path to access the data. I don't know that DDS really makes sense as an intermediate step in any production pipeline, it's more that we have users who just don't know how to get data out of these files at all.
Yeah, I didn't meant to imply OIIO should be integrated into KTX-Software.
FWIW I never thought you were.
I'd be happy enough to see OIIO support something like DDS → RGBA32 (via OpenEXR or KTX2), then at least there is a lossless path to access the data.
If this is just to get access to the data in the DDS file, then okay. If you are going to encode it again in whatever format it started from, the decode-encode will introduce further noise into the image. If the intent is to convert a DDS file to a KTX file it is far better to copy the compressed bits from the DDS container into the new KTX2 container. I'm pretty sure all compressed formats available in DDS/D3D have Vulkan equivalents.