chaiNNer
chaiNNer copied to clipboard
joeyballentine
Many DDS DXT10 formats are not supported
The underlying image library we use does not support many DDS DXT10 formats.
This includes:
- ATI1 (legacy)
- ATI2 (legacy)
- BC1 (all variants)
- BC7 (all variants)
This is pretty critical for games. Any idea what library Chainner would switch to?
@iwubcode we've looked into it and haven't really found anything that can make up for the unsupported formats.
what have you looked at so far?
Me so far: all libraries in pypi.org with the dds tag. I also tried looking for C/C++ libraries, but couldn't find anything multiplatform (yet). DDS support seems to be fairly young over a Rust, so no luck there either.
@RunDevelopment - hmm, surprising there isn't anything. I didn't look extensively but does wand not support those variants? Pillow seemed like it supported BC7 but maybe not BC1.
Wand requires, well, Wand to be installed onto the user's system, so it's not really useful to us even if it can read them.
@RunDevelopment - whoops, glossed over that.
As for C/C++ libraries, there are likely quite a few. I have heard good things about https://github.com/akb825/Cuttlefish . I haven't used it personally however. Nor do I really know what implications that would have triggering it from Chainner. It seems to just be wrapping other libraries so maybe Chainner could use those directly?
This seems interesting, but I'll have to test it. Cuttlefish uses FreeImage to load DDS files and that library doesn't specify which DDS formats are supported.
Could we just look at how some other programs deal with these formats, if they're open source, and just PR pillow with the ability to read them? I think that would be better than adding another dependency
Just tested Cuttlefish CLI. It can't output PNG, so we'd have to write bindings for it ourselves.
About PRing pillow: Have fun. Decoding is implemented in C. You can look at the PR for BC5 to see how much effort it takes to add a single format. Assuming that we do it anyway, PIL releases a new minor around every 2 months, so it might take longer than a month until we actually get to use our PR.
How about we just read the raw files into numpy and write a custom implementation for decoding the data into something usable?
I think you severely underestimate the complexity of DDS formats, but please prove me wrong. It would be awesome if that worked.
@RunDevelopment - I don't know much about it but it looks like there were several dependencies that Cuttlefish was using. I may be wrong but for instance the ISPCTextureCompressor seems to provide a fast speed up for CPUs that support it.
For outputting PNG, couldn't you continue to use whatever you're using now?
@iwubcode Sorry, that's not what I meant. I wanted to use Cuttlefish without making bindings for it, so I looked at the CLI. If the CLI was able to output PNGs, we could ask the CLI to convert DDS to PNG and then read the PNG. I was still just looking for a way to read DDS files.
@RunDevelopment - ah, that makes sense. I've been mostly thinking about writing (as I usually do PNG -> DDS in my own workflow), I suppose you'd want to read as well.