TexConv - Corrupts Alpha Channel In DXT5 Texture about directxtex HOT 12 CLOSED

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.

from directxtex.

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?

from directxtex.

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.

from directxtex.

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

from directxtex.

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.

from directxtex.

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?

from directxtex.

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".

from directxtex.

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.

from directxtex.

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.

from directxtex.

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?

from directxtex.

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.

from directxtex.

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?

from directxtex.