S3 Texture Compression (S3TC) (sometimes also called DXTn, DXTC, or BCn) is a group of related lossy texture compression algorithms originally developed by Iourcha et al. of S3 Graphics, Ltd.[1][2] for use in their Savage 3D computer graphics accelerator.
The method of compression is strikingly similar to the previously published Color Cell Compression,[3] which is in turn an adaptation of Block Truncation Coding published in the late 1970s.
Unlike some image compression algorithms (e.g. JPEG), S3TC's fixed-rate data compression coupled with the single memory access (cf.
Its subsequent inclusion in Microsoft's DirectX 6.0 and OpenGL 1.3 (via the GL_EXT_texture_compression_s3tc extension) led to widespread adoption of the technology among hardware and software makers.
The wide use of S3TC has led to a de facto requirement for OpenGL drivers to support it, but the patent-encumbered status of S3TC presented a major obstacle to open source implementations,[4] while implementation approaches which tried to avoid the patented parts existed.
US 5956431 A) of the multiple USPTO patents on S3 Texture Compression expired on October 2, 2017.
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 4×4 block of pixels to a 64-bit or 128-bit quantity, resulting in compression ratios of 6:1 with 24-bit RGB input data or 4:1 with 32-bit RGBA input data.
S3TC is a lossy compression algorithm, resulting in image quality degradation, an effect which is minimized by the ability to increase texture resolutions while maintaining the same memory requirements.
Hand-drawn cartoon-like images do not compress well, nor do normal map data, both of which usually generate artifacts.
ATI's 3Dc compression algorithm is a modification of DXT5 designed to overcome S3TC's shortcomings with regard to normal maps.
id Software worked around the normalmap compression issues in Doom 3 by moving the red component into the alpha channel before compression and moving it back during rendering in the pixel shader.
[7] 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, although the patent still covers compression algorithms.
The nVidia GeForce 256 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.
DXT1 (also known as Block Compression 1 or BC1) 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
is transparent black corresponding to a premultiplied alpha format.
This color sometimes causes a black border surrounding the transparent area when linear texture filtering and alpha test is used, due to colors being interpolated between the color of opaque texel and neighbouring black transparent texel.
DXT2 and DXT3 (collectively also known as Block Compression 2 or BC2) converts 16 input pixels (corresponding to a 4x4 pixel block) into 128 bits of output, consisting of 64 bits of alpha channel data (4 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
Typically DXT2/3 are well suited to images with sharp alpha transitions, between translucent and opaque areas.
DXT4 and DXT5 (collectively also known as Block Compression 3 or BC3) converts 16 input pixels into 128 bits of output, consisting of 64 bits of alpha channel data (two 8-bit alpha values and a 4×4 3-bit lookup table) followed by 64 bits of color data (encoded the same way as DXT1).
They reuse the alpha channel encoding found in DXT4/5 (BC3).
[9] BC6H and BC7 have a much more complex algorithm with a selection of encoding modes.
Earlier BCn modes decode slightly differently among GPU vendors.
An application would decompress this extra layer and send the BCn data to the GPU as usual.
BCn can be combined with Oodle Texture, a lossy preprocessor that modifies the input texture so that the BCn output is more easily compressed by a LZ77 compressor (rate-distortion optimization).
BC7 specifically can also use "bc7prep", a lossless pass to re-encode the texture in a more compressible form (requiring its inverse at decompression).
[11] crunch is another tool that performs RDO and optionally further re-encoding.
[12] In 2021, Microsoft produced a "BCPack" compression algorithm specifically for BCn-compressed textures.
Xbox series X and S have hardware support for decompressing BCPack streams.