PDA

View Full Version : DDS support?



CortS
07-29-2013, 05:13 PM
Are there any plans to add support for DDS files to the toktx conversion tool, as an input format?

markc
08-12-2013, 01:32 PM
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 (http://imagemagick.org), 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.

CortS
09-16-2013, 01:40 PM
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.

markc
10-01-2013, 12:09 AM
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.