It seems that the tool has a bug with using a transparent (PNG/TGA) for input and converting it to BC3_UNORM_SRGB. Basically I have a texture that uses transparent PNG and I converted it to DDS, while loading it into my code I noticed that mipmap 1 had
problems (mipmap 0 is fine) so naturally I thought it was in my code, but after digging for about 2 hours and running the older DXT5 format throught he same code and not exhibiting the issues I do not think it is my code. Also I can reproduce the exact issue
using the Intel Texture Works plugin (https://software.intel.com/en-us/articles/intel-texture-works-plugin
(Unfortunately I cannot use visual studio as when I load the DDS generated and trying to unselect the alpha channel, I get an HRESULT error code that basically will not allow me to not display alpha. Also the NVIDIA photoshop plugin is now so outdated that
it does not seem to support the new BC formats. And unfortunately the shipped DDSView application does not allow me to view mipmaps.)
I have attached a piece of the source PNG that allows you to reproduce the issue (the original is 4096x4096), the generated DDS and the problematic mip.
The steps are as follows:
1) Convert the PNG using this command line: "texconv -f BC3_UNORM_SRGB -ft DDS test.png"
2) Load the DDS in either custom code or in photoshop using the Intel Texture Workes Plugin.
3) While in photoshop loading using the load all mips.
4) Then select mip 1 and go to Layer->Layer Mask->From Transparency. (Note Mip 0 is fine, but other mips are not, and then at some point, usually around mip 8-10 it is fine again.)
5) Click the chain icon between the newly created layer mask and the layer data
6) Click the layer mask, select all, paint it white (so that it has no transparency)
7) Notice some pixel corruption (consistent with what I see in my application, should be trivial to write an app that loads the DDS and displays mip 1) For convenience I have added test mip1.bmp which shows the resulting problem.
The same problem occurs when using a TGA with 32 bits per channel (also attached).
Current workaround is to open the texture in photoshop and use the Intel Texture Works tools to save out the BC3 DDS with sRGB, this results in the correct image. Unfortunately I have quite a few textures and would rather run them through my automated pipeline
using texconv, so hopefully this issue can be fixed.
Thank you in advance
EDIT: Interestingly enough Intel Texture Work has source code as well... and it seems they build against DirectXTex version 132, whereas the latest code I have is DirectXTex version 134. So perhaps the bug got introduced since then, or perhaps they call it
with different options for conversion (note I did try to use "-nogpu" and a couple other things, but that did not make a difference.)