TexConv - Corrupts Alpha Channel In DXT5 Texture

[FiftyTifty]

After trying multiple combinations of arguments (different mipmap levels, different resolutions, including -pmalpha and/or -sepalpha), it seems that the issue would lie more with TexConv than with anything else.

The texture is the "DirtPath01_D.DDS" that is used by Fallout 4. Running the texture through TexConv causes the alpha to corrupt,

Screenshot of the texture (after being resized through TexConv) itself: http://i.imgur.com/WsUPHd6.png
Screenshot of the texture used in-game: http://i.imgur.com/tGnc66N.png
I've attached an archive containing texconv.exe, the original texture file, the resultant texture file, the texture file to be processed and a .bat file.
Tex.zip

The .dds format used by the texture is BC3_UNORM_2D.

So aye, seems like TexConv doesn't like the alpha channel in that image for some reason, causing the pixels at the edge of the texture (where colour meets 100% transparency) to corrupt. The alpha channel itself, however, looks fine.

[walbourn]

All three of these files look correct on my system.

-m 2 means you are forcing it to only have 2 mipmap levels, which isn't what the "DirtPath01_D - Original, working alpha.DDS" file has which is

DirtPath01_D - Original, working alpha.DDS
Flags 000a1007: CAPS HEIGHT WIDTH PIXELFORMAT MIPMAPCOUNT LINEARSIZE
2048 x 2048
Linear Size: 4194304
Mipmap count: 12
Surface flags: 00401008: COMPLEX TEXTURE MIPMAP
PIXELFORMAT: 00000004: FOURCC
FourCC = 894720068 'DXT5'
DXGI_FORMAT_BC3_UNORM

DirtPath01_D - Resized, broken alpha.DDS
Flags 000a1007: CAPS HEIGHT WIDTH PIXELFORMAT MIPMAPCOUNT LINEARSIZE
512 x 512
Linear Size: 262144
Mipmap count: 2
Surface flags: 00401008: COMPLEX TEXTURE MIPMAP
PIXELFORMAT: 00000004: FOURCC
FourCC = 894720068 'DXT5'
DXGI_FORMAT_BC3_UNORM

Forcing it to use an unusual mipmap count could be part of the problem. For example, VS 2015's DDS viewer won't show any mipmap levels if you have a partial chain. You should probably drop -m from your command line or specifying -m 0 for a full mipmap chain.

[FiftyTifty]

Ah, I should have mentioned. I have resized with the proper mipmaps before, and the result was the same. As well as not specifying any arguments (so just "texconv DirtPath01_D.dds"), and the edge of the texture was still corrupted.

To clarify, are you viewing the texture in Photoshop via the Intel Texture Works plugin?

[walbourn]

I viewed the DDS files in VS 2015, VS 2013, VS 2012, and the legacy DXTex tool from the deprecated DirectX SDK. There's no 'yellow' highlight in any of the three DDS files you sent.

[FiftyTifty]

I'd recommend loading the .dds files in Photoshop, as it has shown that when the texture is run through texconv.exe, it generates that yellow highlight, for another user that bothered to inform me about it. It doesn't seem to be an isolated issue, especially with Fallout 4 itself showing the yellow highlight in-game, when using the "DirtPath01_D - Resized, broken alpha.DDS" texture.

Said user took a video to demonstrate, which can be found @ this post: https://forums.nexusmods.com/index.php?/topic/4789425-resizing-dds-corrupts-edge-blending/?p=41715940

[walbourn]

I see it in your screenshots and in that video, but I don't see it in any viewer I have access to looking at all three DDS files you sent. I'll see if I can track down the Intel viewer.

Generally alpha "corruption" issues have been traced back to WIC using premultiplied alpha for resizing which can damage alpha channels containing something other than transparency. The -sepalpha switch avoids this.

Did you use the prebuilt texconv EXE from GitHub or did you build it yourself?

It is possible that there's a parsing bug in the DDS loader used by Photoshop, Intel, and Fallout 4 but that seems unlikely.

[FiftyTifty]

Ah, I should have mentioned. I'm using the latest released texconv.exe (August 4th) from the releases section. https://github.com/Microsoft/DirectXTex/releases

..Huh. Just ran the .dds through texconv.exe with the -sepalpha flag, and it worked. I swear that it didn't work yesterday when I gave that a go, though I could have been dumb and run it on the already-corrupted texture.

Is there a drawback at all, to including the -sepalpha flag for all .dds files of a given type (e.g, ones containing DXT5 in their header), or is it just a failsafe measure that increases processing time?

[walbourn]

Intel's photoshop plugin uses DirectXTex for the file I/O, but they have their own view and BC compression code. They have it on GitHub, but without source. You should file an issue on their GitHub giving them the DDS file that shows up "yellow".

[FiftyTifty]

Guess I can fire 'em a wee inquiry about it. Is the intention ta get them to share their BCn compression stuff, to cross-reference?

Did a wee bit of testing, and found something interesting.

If I resize the .dds (without the -sepalpha flag), it corrupts the edges.

If I resize the .dds (also without the -sepalpha flag) and output it as .png, the edges aren't corrupted.

If I then take the resultant .png file and run it through texconv (with or without specifying the argument -f BC3_UNORM), to convert it to .dds, the edges corrupt.

[walbourn]

Just to confirm, if you view your "corrupted" DDS files in Visual Studio, do you actually see yellow or not? I suspect there's a bug in the Intel decompression code that may have gotten copied into Fallout.

[FiftyTifty]

Alas, I don't have the foggiest idea on how to do that; I'm not even a C# programmer (this Texture Resizer program is my first foray into the language), let alone a C++ guy.

Is there a viewer (or something to that effect) bundled with DirectXTex that I can compile and chuck the .dds into (a la texconv through passing arguments to a command line)? Or is it a bit more complicated than that?

[walbourn]

You can just use Visual Studio to open the DDS file and it will let you view it.

You can safely use -sepalpha for all your processing, it is just less efficient since it effectively resizes the image twice. If you don't know if the source image is using alpha for something other than transparency, that's probably the safest bet.

[FiftyTifty]

Huh, didn't know VS could do that. Yup, it shows the texture file without the corrupted edges. I'll go fire this on over to the Texture Works plugin.

And sweet. If there's no alpha data, will -sepalpha cause any untoward problems? Just tried it on a texture with no alpha, and it didn't do anything strange to the texture, so I assume it's safe?