S3 Texture Compression

From Wikipedia, the free encyclopedia

S3 Texture Compression (S3TC) (sometimes also called DXTn or DXTC) is a group of related image compression algorithms originally developed by Iourcha et al of S3 Graphics, Ltd. (US Patent 5,956,431) for use in their Savage 3D computer graphics accelerator. Unlike some image compression algorithms (e.g. JPEG), S3TC's fixed-rate data compression coupled with the single memory access (cf. some VQ-based schemes) made it ideally suited for use in compressing textures in hardware accelerated 3D computer graphics. Its subsequent inclusion in Microsoft's DirectX 6.0 led to widespread adoption of the technology among hardware and software makers. While S3 Graphics is no longer a leading competitor in the graphics accelerator market, license fees are still levied and collected for the use of S3TC technology, for example in consoles.

1 Codecs
2 DXT1
3 DXT2 and DXT3
4 DXT4 and DXT5
5 S3TC Format Comparison
6 See also
7 External links

[edit] Codecs

There are five variations of the S3TC algorithm (named DXT1 through DXT5, referring to the FOURCC code assigned by Microsoft to each format), each designed for specific types of image data. All convert a 4x4 block of pixels to a 64-bit or 128-bit quantity, resulting in compression ratios of 8:1 or 4:1 with 32-bit RGBA input data. S3TC is a lossy compression algorithm, resulting in image quality degradation, but for most purposes the resulting images are more than adequate. (The notable exception is the compression of normal map data, which usually results in annoyingly visible artifacts. ATI's 3Dc compression algorithm is a modification of DXT5 designed to overcome S3TC's shortcomings in this area.)

Like many modern image compression algorithms, S3TC only specifies the method used to decompress images, allowing implementers to design the compression algorithm to suit their specific needs. The early compression routines were not optimal, and although since greatly improved, hindered early adoption of S3TC by developers. The nVidia GeForce 1 through to GeForce 4 cards also used 16 bit interpolation to render DXT1 textures, which resulted in banding when unpacking textures with color gradients. Again, this created an unfavorable impression of texture compression, not related to the fundamentals of the codec itself.

[edit] DXT1

DXT1 is the smallest variation of S3TC, storing 16 input pixels in 64 bits of output, consisting of two 16-bit RGB 5:6:5 color values and a 4x4 two bit lookup table.

If the first color value ( $c 0$ ) is numerically greater than the second color value ( $c 1$ ), then two other colors are calculated, such that $c_2 = {2 \over 3} c_0 + {1 \over 3} c_1$ and $c_3 = {1 \over 3} c_0 + {2 \over 3} c_1$ .

Otherwise, if $c_0 \le c_1$ , then $c_2 = {1 \over 2} c_0 + {1 \over 2} c_1$ and $c 3$ is transparent.

The lookup table is then consulted to determine the color value for each pixel, with a value of 0 corresponding to $c 0$ and a value of 3 corresponding to $c 3$ . DXT1 does not store alpha data enabling higher compression ratios.

[edit] DXT2 and DXT3

DXT2 and DXT3 converts 16 input pixels into 128 bits of output, consisting of 64 bits of alpha channel data (four bits for each pixel) followed by 64 bits of color data, encoded the same way as DXT1 (with the exception that the 4 color version of the DXT1 algorithm is always used instead of deciding which version to use based on the relative values of $c 0$ and $c 1$ ). In DXT2, the color data is interpreted as being premultiplied by alpha, in DXT3 it is interpreted as not having been premultiplied by alpha. Typically DXT2/3 are well suited to images with sharp alpha transitions, between translucent and opaque areas.

[edit] DXT4 and DXT5

DXT4 and DXT5 converts 16 input pixels into 128 bits of output, consisting of 64 bits of alpha channel data (two 8 bit alpha values and a 4x4 3 bit lookup table) followed by 64 bits of color data (encoded the same way as DXT2 and DXT3).

If $α 0 > α 1$ , then six other alpha values are calculated, such that $\alpha_2 = {{6\alpha_0 + 1\alpha_1} \over 7}$ , $\alpha_3 = {{5\alpha_0 + 2\alpha_1} \over 7}$ , $\alpha_4 = {{4\alpha_0 + 3\alpha_1} \over 7}$ , $\alpha_5 = {{3\alpha_0 + 4\alpha_1} \over 7}$ , $\alpha_6 = {{2\alpha_0 + 5\alpha_1} \over 7}$ , and $\alpha_7 = {{1\alpha_0 + 6\alpha_1} \over 7}$ .

Otherwise, if $\alpha_0 \le \alpha_1$ , four other alpha values are calculated such that $\alpha_2 = {{4\alpha_0 + 1\alpha_1} \over 5}$ , $\alpha_3 = {{3\alpha_0 + 2\alpha_1} \over 5}$ , $\alpha_4 = {{2\alpha_0 + 3\alpha_1} \over 5}$ , and $\alpha_5 = {{1\alpha_0 + 4\alpha_1} \over 5}$ with $α 6 = 0$ and $α 7 = 255$ .

The lookup table is then consulted to determine the alpha value for each pixel, with a value of 0 corresponding to $α 0$ and a value of 7 corresponding to $α 7$ . DXT4's color data is premultiplied by alpha, whereas DXT5's is not. Because DXT4/5 use an interpolated alpha scheme, they generally produce superior results for alpha (transparency) gradients than DXT2/3. Some consider DXT5 to be the most flexible general purpose compression codec.

[edit] S3TC Format Comparison

FOURCC	Description	Alpha premultiplied?	Compression ratio	Texture Type
DXT1	Opaque / 1-bit Alpha	N/A	8:1 / 6:1	Simple non-alpha
DXT2	Explicit alpha	Yes	4:1	Sharp alpha
DXT3	Explicit alpha	No	4:1	Sharp alpha
DXT4	Interpolated alpha	Yes	4:1	Gradient alpha
DXT5	Interpolated alpha	No	4:1	Gradient alpha