Bug with alpha channel values

[gorunovanton]

When FasTC is compressing images with alpha channel filled with distinct values to BPTC compression format, there are few blocks which should contain uniform alpha 255 values, but certain pixels has wrong alpha values: 254 instead of 255. Those blocks can be located far from the blocks containing alpha channel values less than 255.

For example, bug appears after compressing this image:
https://dl.dropboxusercontent.com/u/3319885/source.png
The result of compression:
https://dl.dropboxusercontent.com/u/3319885/result-bptc.png
Part of damaged pixels marked at this area:
https://dl.dropboxusercontent.com/u/3319885/bug-area.png

Our renderer's dithered transparency algorithm erroneously discards those pixels with alpha = 254, leading to completely solid objects having random single-pixel holes :(. But expected value for those pixels is 255 as in source texture. Is there any chance to figure out what's going on, or maybe even fix it?
Thanks for attention.

[Mokosha]

I tracked down the problem:

BC7 includes a new compression option per-block known as a p-bit. This is a bit that is shared across the LSB of all color channels in any given block. The compressor treats all channels equally in terms of error. It does this because some textures store non-color information, and there is no imperative to preserve the error in some channels versus others.

To make it a bit more clear, the way BC7 works is to choose two end points (in RGB(A) space) and interpolate colors in between them. For this particular instance, the endpoints are represented using seven bits per channel with a per-endpoint p-bit (Mode 6). This means that in order to get fully opaque alpha for the entire block, the p-bit must be one for both endpoints. However, it introduces less error across all channels to keep the p-bit as zero for one of the endpoints. This means that alpha values chosen closer to that endpoint will be

0b 1111111 0   == 0xFE == 254
   |-----| ^-----  p-bit
      ^--- stored full alpha end point

The best way to fix this is probably to add one of two options to FasTC:

• BC7 specific option to preserve alpha and only use opaque block modes for opaque input. This will introduce a bit of error to the compressor but also add a bit of speed.
• Allow the user to specify per-channel weights for any of the compression modes and use that to gauge error across channels