DTX1 is decoded incorrectly

[drewcassidy]

DTX1 is decoded incorrectly

[drewcassidy]

See this is the thing: there kinda isn't a format specification since DXT1 originated as a semi-proprietary format of a now-defunct graphics company. Microsoft's docs for BC1 (their name for DXT1 in DirectX 11) just says

This algorithm lends itself to data that contains 1-bit alpha also.

Without specifying if the alpha should always be there or not. The OpenGL wiki states

A DXT1-compressed image is an RGB image format. As such, the alpha of any color is assumed to be 1

and treats "DXT1 with alpha" as a separate pseudo-format. The Nvidia Texture Tools toolset treats it the same way, and as far as I can tell this was the original intention of the format with the alpha information tacked on after the fact.

In the end there's not much consensus with these formats besides what the GPUs themselves will accept, and its impossible to make it in a way that pleases everyone with all these fuzzy rules in place

[drewcassidy]

This is the default behavior, since a lot of BC1 textures are designed around the transparent pixels being decoded as black. The solution is to pass an instance of BC1Decoder with write_alpha set to true, though I guess that isn't very convenient when using the dds.read function. I'll look into a better solution

[RunDevelopment]

So the default behavior is to ignore transparent pixels and use black instead? May I ask in what context it is useful to ignore the transparency of DDS images and (effectively) apply a black background?

[drewcassidy]

BC1 is MOSTLY used for images without transparency. This allows for the transparent pixels to be used for black in order to get better quality, a trick quicktex and many other encoders employ

[RunDevelopment]

Is this behavior covered by the format specification?

[RunDevelopment]

You are right. It seems like I assumed that DXT1 was more similar to BC1_UNORM_SRGB than it actually is.