BC7 (no GPU) compresses (255,255,255,0) to (255,255,255,1)

An image with a block of fully transparent white texels is getting compressed to white texels with an alpha value of 1 instead of 0.

To reproduce:

Take a 4x4 image where each uncompressed texel is (255,255,255,0)
(I have attempted to attach such an image, but it's not clear to me whether the attachment process worked)
Enter the following command in texconv:
texconv.exe -f BC7_UNORM -nogpu transparentWhite.png
Observe that the resulting compressed texels are (255,255,255,1), and no longer fully transparent

Note that if GPU compression is used the compressed values are the expected (255,255,255,0), and so the undesired alpha value only happens with non-GPU compression.

When I run the CPU-compressor on the latest version of the library, I get a block (as decoded by texdiag)

Compression: BC7_UNORM
Results by item (  1) and mip (  1)
   Block 0 (pixel: 0 x 0)
        Mode 6 - [7 7 7 A7]
                 C0:(1.000, 1.000, 1.000)
                 C1:(1.000, 1.000, 1.000)
                 A0:(0.004)
                 A1:(0.004)
              Index: 0 0 0 0 | 0 0 0 0 | 0 0 0 0 | 0 0 0 0

And it's getting decoded as (255,255,255,0).

Hi, thanks for responding!

I didn't know about that ability in texdiag, but that's useful. I don't know understand BC7 compression enough to know how to interpret those values, but I definitely see a non-zero value in the alpha channel for me visually (that's how I discovered the issue) and I see a 1 when I look at the texture in the ways that I know how to quantitatively:

Dragging and dropping the DDS file into Visual Studio and using the color picker (this I think you should be able to replicate)
Making a capture of my application with either the Visual Studio Graphics Analyzer or Render Doc and looking at the D3D resource (which you wouldn't be able to do without my application, and which isn't as direct a test anyway since it uses DirectXTex code directly and has a custom texture format that I generate rather than DDS)

If you drag and drop the DDS into Visual Studio and use a color picker do you see (255,255,255,0)? I see (255,255,255,1).

If I were to speculate what the output of texdiag means, since it shows 0.004 for both A0 and A1, and 0.004*255=1.02, are you sure that it doesn't confirm what I am seeing that the value is (255,255,255,1)?

Just as a comparison, this is what texdiag outputs when I use GPU compression and where I get the desired (255,255,255,0):

Compression: BC7_UNORM
Results by item (  1) and mip (  3)

[  0,   0]:
   Block 0 (pixel: 0 x 0)
        Mode 4 - [5 5 5 A6] indx mode 2-bit, rot-bits 0
                 C0:(1.000, 1.000, 1.000)
                 C1:(1.000, 1.000, 1.000)
                 A0:(0.000)
                 A1:(0.000)
            Colors: 0 0 0 0 | 0 0 0 0 | 0 0 0 0 | 0 0 0 0
             Alpha: 0 0 0 0 | 0 0 0 0 | 0 0 0 0 | 0 0 0 0

There A0 and A1 both show 0, which seems to fit with what I am seeing empirically.

I see the '0.004' vs. '0.0`` issue is there. It's probably more prominent for alpha than color. I suspect the difference here is that the GPU compressor operators on UNORM formats while the CPU compressor uses floating point. Not quite sure how I'd fix this, but I'll keep it open.

I've seen these same issues before, it's mode 6 being used with p-bits set to 1. Can't get around that. For images like these you should set alpha to 1 (fully opaque) and let the encoder decide the best mode

Navigation Menu

Repository navigation

BC7 (no GPU) compresses (255,255,255,0) to (255,255,255,1) #269

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

BC7 (no GPU) compresses (255,255,255,0) to (255,255,255,1) #269

Description

Activity

walbourn commented on Mar 23, 2022

jpownby-es commented on Mar 24, 2022

walbourn commented on Mar 24, 2022

jandk commented on Aug 11, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions