Garbage on decompressed BC7 textures

[gildor2]

Hello.

You're doing very useful project. I have a project where I have texture decompression functionality. For years I used NVidia Texture Tools library, but it is very outdated and has no support for modern and mobile texture formats. So I tried to replace it with your "detex" library. However I have some problems with BC7 format decompression (I tried your library for BC7 and ETC formats - ETC1 works well, ETC2 decompression is completely wrong - but that's another issue ...)

I have code which loads BC7 textures using OpenGL, and it works well. Here you may see a screenshot of correct texture (I found a very simple one):

By the way, if I'll disable this OpenGL functionality, texture looks different - it has some color spots:

The same happens with nearly all BC7 textures. Probably I'm doing something wrong and decompressor requires some additional settings?

I can provide sample files (but I'll need to understand how to save them either in DDS or KTX format).

I hope for your support.

Thanks,
Konstantin

[hglm]

Hi,

Thanks for your feedback.

It looks like there is a bug in the BC7 decompression of a certain mode (BC7 has eight different block modes) that causes blocks compressed using that mode to be wrong. I will investigate this issue.

I would be interested in a sample file, but I will also look on the internet for more sample files.

One thing I have been planning to do is to add an OpenGL validation program to detex to test the compression algorithms in a reliable way. That should help catch more bugs and eliminate them.

I'll keep you posted on this issue.

[gildor2]

Hi,

Thank you for the prompt response. I can provide you a sample file, but it is stored in binary form - so I have image data block and some information which should be filled into headers. Is there a quick way to combine them into a form of DDS or KTX?

NVTexTools has DDS saving function, but it is unaware of BC7 format.

[hglm]

I can handle a raw binary file. Combining them into a raw DDS file requires a little work, it would be possible using the detexSaveDDSFile function in detex. Something like:

detexTexture texture;
texture.width = 128;
texture.height = 128;
texture.width_in_blocks = 32;
texture.height_in_blocks = 32;
texture.format = DETEX_TEXTURE_FORMAT_BPTC;    // BPTC is same as BC7
texture.data = LoadFileIntoBuffer("texture_file.raw");
detexSaveDDSFIle(&texture, "texture_file.dds");

I tested some BC7 files generated using the new AMDCompressCLI utility in Windows (available from amd.com), and they seem to decompress correctly using detex (tested with detex-view). Maybe it doesn't use the compression mode that gives problems in your texture files.

[gildor2]

I've produced DDS file with your instructions, but I have no tool which could display BC7 DDS contents for verification. So I've included "raw" version as well.
The file is here (GitHub doesn't allow to attach it)
http://www.gildor.org/down/39/temp/texture.zip

[hglm]

Thanks, I will investigate the problem. I can trace which BC7 modes cause the problem, which should point to the right direction.

[hglm]

OK, it looks like BPTC mode 5 (out of 0 to 7) is causing the problem. This should be fixable.

[gildor2]

Thanks a lot for looking at this problem!

[hglm]

There was indeed a bug in the handling of mode 5. The code assumed certain bitfields used for mode 5 do not cross a 64-bit boundary, but they do. It should be fixed now.

[gildor2]

Thank you very much! It works well now.

[gildor2]

Sorry, I mentioned before that ETC2 format doesn't work. I was wrong: I've re-checked data and found that data I thought are in ETC2 format really stored uncompressed.