NV TT Exporter ASTC compression

What file extension should I use when saving a texture with ASTC compression? If I save to DDS, the DDS header looks correct with the format set to 134. Is there a DDS format enum which maps 134 to ASTC?

Thank you

Hi Manas!

These use the extended DXGI formats including ASTC, which take up DXGI formats 133 to 187 - you can find them listed in a few places, such as https://github.com/bkaradzic/bgfx/blob/master/src/renderer_d3d.h#L22 or https://gli.g-truc.net/0.6.1/api/a00001.html.

Note that these won’t be supported by all DDS readers, as they were only briefly part of the DXGI format spec (the best historical resource I have on these is that they were added to the spec by Microsoft, then removed).

The Texture Tools Exporter always writes the formats with the _UNORM suffix, which are formats 134 (4x4), 138 (5x4), 142 (5x5), …, 186 (12x12). These correspond to the GL_COMPRESSED_RGBA_ASTC_nxm_KHR formats, so for instance DXGI_FORMAT_ASTC_4X4_UNORM is the same as GL_COMPRESSED_RGBA_ASTC_4x4_KHR.

Hope this helps!

Since ASTC formats are not officially in DXGI spec, would you recommend another container to store the ASTC texture? We are currently storing ASTC in a KTX container with our in-house texture tool but were looking at yours since it supports a lot more features. But I didn’t see KTX in NV TT supported formats when trying to save the file.

KTX isn’t in the Texture Tools Exporter yet, but I’m looking at adding support for it in the future (since it has official support for modern texture formats, as you mentioned)! If you only have a KTX reader, it is possible to take data from DDS files in the formats the Texture Tools Exporter and convert them to KTX format by getting the data from the DDS file directly, but it’s a bit of a manual process that you’d need a tool for (though I’m happy to help with information on where to get the things you need from the DDS file).

Hi Nick, the tool definitely looks interesting as we could use dds for all our target platforms.
Does NV TT internally use the features from astcenc like normal psnr for normal maps? I can’t find it in the interface. Additionally, is there a command line tool?

Thank you

Hi manaskulkarni!

The Texture Tools Exporter standalone can also be used as a command-line tool - run nvtt-export.exe --help from a command line to see the help dialog! (nvtt-export.exe runs in GUI mode when run without arguments or with no arguments other than a filename, and otherwise runs in command-line mode.) This also allows you to access nvtt-export's batch mode. For more information, see the Fully Automatable section at the bottom of this article: https://news.developer.nvidia.com/texture-tools-exporter-2020-1/

Unfortunately, I’m not totally sure what you’re referring to by astcenc's normal PSNR - could this be the way astcenc stores normal maps when using the -normal flag (i.e. only storing the two lateral channels), the dblimit flag (that stops searching when a given PSNR is reached), or the ability to report compressed PSNR?

For the first, the Texture Tools Exporter currently supports BC3n, which does a similar thing using the BC3 format (it removes the Z channel, then copies the X channel to the alpha channel) - this makes sense here, because BC3 stores compressed RGB data separately from compressed alpha data. The Texture Tools Exporter doesn’t currently have something like this for other formats such as BC7 because of this feature unique to BC3 and because there are more methods for storing normals than I can quite enumerate (e.g. octahedron normal vector encoding, or Crytek’s normal encoding, for which I figure it might be easier for developers to implement their own normal encoding and decoding methods, then compress using NVTT).

The Texture Tools Exporter doesn’t quite have equivalents for the second and third yet - it has a way for you to set the quality-time tradeoff, but the compressors generally try to do the best they can within some computational complexity bound. It also doesn’t have a PSNR meter at the moment, but this may be added in the future.

Best regards!