-
Notifications
You must be signed in to change notification settings - Fork 230
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fully support DDS to KTX2 pipeline #92
Comments
Contributions will be gratefully received. |
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:
However, we've found OIIO's support for compressed DDS files and cubemaps to be ... less than complete (mrdoob/three.js#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 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 |
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.
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. |
FWIW I never thought you were.
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. |
We should provide a straightforward and well-supported way of producing KTX2 files from DDS.
An official open-source DDS implementation is here.
The text was updated successfully, but these errors were encountered: