The Khronos Group - a non-profit industry consortium to develop, publish and promote open standard, royalty-free media authoring and acceleration standards for desktop and handheld devices, combined with conformance qualification programs for platform and device interoperability.

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Are there any plans to add support for DDS files to the toktx conversion tool, as an input format?

I want to avoid needing a huge list of dependencies to build toktx. That is why it only includes a PBM reader. You can easily find tools, such as ImageMagick, to convert most formats to PBM. Note: I'm not saying reading DDS containers needs lots of dependencies. I have not looked yet. If you have pointers to the source of a DDS reader, please post them here. If I can find a small DDS file reader I will certainly consider adding support to rewrap the images from a DDS file as a KTX file. However I do not plan to add image format conversion to toktx. You can use external tools for that.

Hi Mark -- I definitely understand the desire to minimize the number of external dependencies. The easiest way to parse DDS files is to use the DirectX SDK, but it's certainly possible to implement a stand-alone, single-C-file DDS reader. I had to write one a few years ago at work, actually (~900 LOC). I may have some similar code from a personal project that I could contribute as a reference; let me poke around for a bit.

I can also appreciate the desire not to clutter the tool with unnecessary and redundant image-conversion features, in light of existing converters like ImageMagick, but I still think DDS support would add significant value. DDS isn't just another 2D image format -- it's one of the only widely-supported container formats that natively supports multi-surface objects like cubic environment maps, mipmap chains, volume textures and texture arrays, as well as popular block-compressed texture formats (DXTn/BCn). Converting a mipmapped volume texture from DDS to KTX via individual PBM slices would be tedious, error-prone, and could potentially include a lossy (and CPU-intensive) decompression/recompression step. A direct conversion could probably just copy the DDS pixel data directly, and change only the file headers and metadata.

Hi Mark -- I definitely understand the desire to minimize the number of external dependencies. The easiest way to parse DDS files is to use the DirectX SDK, but it's certainly possible to implement a stand-alone, single-C-file DDS reader. I had to write one a few years ago at work, actually (~900 LOC). I may have some similar code from a personal project that I could contribute as a reference; let me poke around for a bit.

I can also appreciate the desire not to clutter the tool with unnecessary and redundant image-conversion features, in light of existing converters like ImageMagick, but I still think DDS support would add significant value. DDS isn't just another 2D image format -- it's one of the only widely-supported container formats that natively supports multi-surface objects like cubic environment maps, mipmap chains, volume textures and texture arrays, as well as popular block-compressed texture formats (DXTn/BCn). Converting a mipmapped volume texture from DDS to KTX via individual PBM slices would be tedious, error-prone, and could potentially include a lossy (and CPU-intensive) decompression/recompression step. A direct conversion could probably just copy the DDS pixel data directly, and change only the file headers and metadata.

I agree. If you can find that code please send it. Actually I will soon move the KTX source to Github so you will be able to just send a pull request.