Skip to content
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

Open
lexaknyazev opened this issue Jul 7, 2019 · 6 comments
Open

Fully support DDS to KTX2 pipeline #92

lexaknyazev opened this issue Jul 7, 2019 · 6 comments

Comments

@lexaknyazev
Copy link
Member

We should provide a straightforward and well-supported way of producing KTX2 files from DDS.
An official open-source DDS implementation is here.

@MarkCallow
Copy link
Collaborator

MarkCallow commented Jul 7, 2019

Contributions will be gratefully received.

@Ben-Mack
Copy link

Yes, DDS to KTX and KTX2 would be great. Does anyone know which tool can do this conversion? I've been looking for it

@donmccurdy
Copy link
Contributor

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 (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. 🙏

@MarkCallow
Copy link
Collaborator

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.

@donmccurdy
Copy link
Contributor

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.

@MarkCallow
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants