DXT5 for highquality texturecompression

I’ve done some texturecompression experiments:
A picture for comparing uncompressed, DXT1,indexed and a DXT5 based compression: http://cpux.de/base/compression1.png

The DXT5 based compression needs a single multiplcation in a shader (or blending) for decompression:

uniform sampler2D Colormap;
void main(void){
        vec4 color = texture2D(Colormap, vec2(gl_TexCoord[0]));
        gl_FragColor = color * color.a;
        }  

I’ve create the compressed pic by using Gimp:

  1. Load a RGB image.
  2. Create a Alpha chanel from a black color (Colors->Color to Alpha)
  3. Save that as DXT5 compressed DDS (needs a plugin)

This variant is not perfect, because the color is quantised to 5 or 6 bits, but curently I’m working on a plugin for cinepaint, that could compensate the quantisationerror in the alpha compression. So the Luninace will get a higher dynamic range somewhere between 10bit (60dB) to 14bit (84dB)
(That means, that a picture compressed with this method, will have a higher SNR for luminace and a lower SNR for Color as uncompressed 24 bit images)

I’m thinking about using a nonlinear alpha curve too. That could reach the signal/noise ratio for dark colors wich are brightened by near or bright lightsources, but will lower the ratio for light colors. When the DXT decompression units would run with a higher precision (no colorbanding below 8 bit), a full 16 bit (96dB) dynamic range should be possible. (with only 8 bit / Textel :smiley: )

Have look at:
http://www.humus.ca/index.php?page=3D&ID=68

Originally posted by sqrt[-1]:
Have look at:
http://www.humus.ca/index.php?page=3D&ID=68

Im not sure ATI1N is supported in OpenGL

Just use GL_LUMINANCE8 for Y and GL_LUMINANCE8_ALPHA8 for Cr and Cb… This is a really nice compression method, it’s a shame it needs two texture samplers though :-/ It is a time for a “composite texture” extension :slight_smile:

P.S. I would like to see some tests with compressed sRGB textures.

I know humus site.
The two samples are in many cases not possible. DXT5 with the additional multiplication, looks like one of the best. The only problem is to write an optimised encoder ( that will take a little time :wink: ).

oc2k1 take a look at this :

‘Real-Time DXT Compression’
by J.M.P. van Waveren of id Software

http://www.intel.com/cd/ids/developer/asmo-na/eng/324337.htm

Hope it’s inspiring !

I think it could help at the color part. My current version is only fast, but gives a to bad quality for the next compression step (I need better base colors) One smal problem is that the known algorithms don’t weight the colors by luminance (a black color shouldn’t have an effect on the two reference colors)

The big question is why nobody use the additional bits in the DXT5 color part, to store an RGB value instead CrCb that needs more instructions to decode and waste 5 bits.

Another idea would be to store a common exponent or factor for the complente block. If only 11 bit for CrCb are used, there are 5 remaining bits, that could raise the dynamic range extremly if they are used as common exonent for the aplpha value.