richgel999 / bc7enc Goto Github PK

Just want to say thank you for that encoder. It works great. I am working on texture converter for a game to let users ability to convert modded textures from PNG to DDS format. Was using ImageMagick (DXT5), but DDS files converted with this encoder makes textures to look much better. I really like that bc7enc can be compiled on Linux and MacOS (instead of Texconv, for example), so tool may become cross-platform. The only thing I am missing is mipmaps creation.
Thank you for your time and work!

P. S. Wrong repo, I use latest RDO edition.

Hi, @richgel999. Thanks for the great compressor and your work along the years.

This issue isn't something new, because AMD Compressonator suffers from the exact same artifacts, and I know some kind of degradation is to be expected. There are format limitations and the RGB part may be eating all the bits.

I find it interesting that, while lower quality, using an older BC3 compressor produces a much more coherent image. Because I don't know if this is an isolated/edge case I figured bringing it up and posting actual samples would help. ¯\_(ツ)_/¯

Here's bc7enc's unpacked alpha:

Here's the result on a white background:

Here are the AMD Compressonator 4.0.4855 results, with their staircasing counterparts:

Or, who knows, maybe I'm using it wrong. The problem doesn't look that ugly on a gray or checkerboard background, but it's really apparent against bright and contrasty gradients.

Between the curve, the sudden color and alpha changes and all the noise these logos may be a tough case. On my end of the content pipeline I think they'll have to live uncompressed for now. They don't pass the quality check.

In kramv, I kept seeing BC1 errors with a texture that I've linked to. It's a color texture with mostly grayscale in it. And green, yellow, and purple blocks would appear in the image where there were none originally. With the block view, I could tell these were erroneous constant blocks.

I think I might have found the issue. By decrementing the min16--, if the last color value is 0, then the entire color rolls over and can set high red or blue colors to high values. That's fine provided that color isn't the one picked from the selectors, but the selectors look like they're reversed and picking the modified color (or the non-zero color). I also added some 'else' statements, and consolidated the flow is a little clearer.

I didn't yet check the other encoders to see if this same logic was repeated.

https://github.com/alecazam/kram/blob/main/tests/src/Toof-a.png
kram encode -v -f bc1 -srgb -i ~/kram/tests/src/Toof-a.png -o ~/kram/tests/out/mac/Toof-fixbc1-a.ktx

void encode_bc1_solid_block(void* pDst, uint32_t fr, uint32_t fg, uint32_t fb, bool allow_3color) 
{
		... I have allow_3color disabled, so it goes directly into this code

if (max16 == -1)
{
    // 565 endpoints, these should be same color
    max16 = (g_bc1_match5_equals_1[fr].m_hi << 11) | (g_bc1_match6_equals_1[fg].m_hi << 5) | g_bc1_match5_equals_1[fb].m_hi;
    min16 = (g_bc1_match5_equals_1[fr].m_lo << 11) | (g_bc1_match6_equals_1[fg].m_lo << 5) | g_bc1_match5_equals_1[fb].m_lo;

    if (min16 == max16)
    {
        // Always forbid 3 color blocks
        // This is to guarantee that BC3 blocks never use punchthrough alpha (3 color) mode, which isn't supported on some (all?) GPU's.
    
        // Make l > h
        if (min16 > 0)
        {
            mask = 0x55; // b01 x 4, choose max = color, <- was b00 x 4 which picks modified min 
            
            min16--; // this can raise channels if b is 0, but mask ignores min color
        }
        else
        {
            mask = 0; // b00 x 4, choose min = 0,  <- was 0x55 b01 x 4 which picks modified max16 = 1 which isn't original min16=max16=0 
            
            // l = h = 0
            assert(min16 == max16 && max16 == 0);

            // here we know both colors are 0, so make max16 bigger
            max16 = 1;
            min16 = 0;
        }

        assert(max16 > min16);
    }
    else if (min16 > max16)
    {
        std::swap(max16, min16);
        mask ^= 0x55; // b01 x 4, choose max
    }

....
}

Sorry for the noob question.

I'm trying to compress attached image to dxt1 (bc1) and caclulate PSNR:
.\bc7enc.exe -1 -u5 -i -b -n .\Sky_1k.png Sky_1k.dds

After compression I'm getting:

Luma  Max error:  12 RMSE: 0.916742 PSNR 48.89 dB
RGB   Max error:  18 RMSE: 1.124917 PSNR 47.11 dB
RGBA  Max error:  18 RMSE: 0.974207 PSNR 48.36 dB
Red   Max error:  18 RMSE: 1.197769 PSNR 46.56 dB
Green Max error:  12 RMSE: 0.957731 PSNR 48.51 dB
Blue  Max error:  15 RMSE: 1.201839 PSNR 46.53 dB
Alpha Max error:   0 RMSE: 0.000000 PSNR 100.00 dB

If I want to use 3rd party tool like Microsoft's texdiag.exe (texdiag.zip) and calculate PSNR using it I'm getting following results (./texdiag.exe compare Sky_1k.png Sky_1k.dds):

Result: 0.000059 (0.000023 0.000014 0.000022 0.000000) PSNR 47.041554 dB

However, if I will compare unpacked png (.\texdiag.exe compare .\Sky_1k.png .\Sky_1k_unpacked.png):

Result: 0.000058 (0.000022 0.000014 0.000022 0.000000) PSNR 47.109453 dB

which is close to the RGB Max Error from bc7enc tool.

Does it mean that it's not possible to directly compare files without constant unpacking them?

Is there any possibility of adding support for 1-bit alpha in the BC1 encoder?