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. for use in their Savage 3D computer graphics accelerator . The method of compression is strikingly similar to the previously published Color Cell Compression , 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. Color Cell Compression and some VQ -based schemes) made it well-suited for use in compressing textures in hardware-accelerated 3D computer graphics . 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. While S3 Graphics is no longer a competitor in the graphics accelerator market, license fees have been levied and collected for the use of S3TC technology until October 2017, for example in game consoles and graphics cards. 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, while implementation approaches which tried to avoid the patented parts existed.
31-555: Some (e.g. US 5956431 A) of the multiple USPTO patents on S3 Texture Compression expired on October 2, 2017. At least one continuation patent, US6,775,417 , however had a 165-day extension. This continuation patent expired on March 16, 2018. 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
62-552: A Uniform Type Identifier and are no longer used as the primary data type signature. Mac OS X (macOS) prefers the more colloquial convention of labelling file types using file name extensions. At the time of the change, the change was a source of great contention among older users, who believed that Apple was reverting to a more primitive way that misplaces metadata in the filename. Filesystem-associated type codes are not readily accessible for users to manipulate, although they can be viewed and changed with certain software, most notably
93-455: A "BCPack" compression algorithm specifically for BCn-compressed textures. Xbox series X and S have hardware support for decompressing BCPack streams. FourCC A FourCC ("four-character code") is a sequence of four bytes (typically ASCII ) used to uniquely identify data formats . It originated from the OSType or ResType metadata system used in classic Mac OS and was adopted for
124-2710: A 4×4 3-bit lookup table) followed by 64 bits of color data (encoded the same way as DXT1). If α 0 > α 1 {\displaystyle \alpha _{0}>\alpha _{1}} , then six other alpha values are calculated, such that α 2 = 6 α 0 + 1 α 1 7 {\textstyle \alpha _{2}={{6\alpha _{0}+1\alpha _{1}} \over 7}} , α 3 = 5 α 0 + 2 α 1 7 {\textstyle \alpha _{3}={{5\alpha _{0}+2\alpha _{1}} \over 7}} , α 4 = 4 α 0 + 3 α 1 7 {\textstyle \alpha _{4}={{4\alpha _{0}+3\alpha _{1}} \over 7}} , α 5 = 3 α 0 + 4 α 1 7 {\textstyle \alpha _{5}={{3\alpha _{0}+4\alpha _{1}} \over 7}} , α 6 = 2 α 0 + 5 α 1 7 {\textstyle \alpha _{6}={{2\alpha _{0}+5\alpha _{1}} \over 7}} , and α 7 = 1 α 0 + 6 α 1 7 {\textstyle \alpha _{7}={{1\alpha _{0}+6\alpha _{1}} \over 7}} . Otherwise, if α 0 ≤ α 1 {\textstyle \alpha _{0}\leq \alpha _{1}} , four other alpha values are calculated such that α 2 = 4 α 0 + 1 α 1 5 {\textstyle \alpha _{2}={{4\alpha _{0}+1\alpha _{1}} \over 5}} , α 3 = 3 α 0 + 2 α 1 5 {\textstyle \alpha _{3}={{3\alpha _{0}+2\alpha _{1}} \over 5}} , α 4 = 2 α 0 + 3 α 1 5 {\textstyle \alpha _{4}={{2\alpha _{0}+3\alpha _{1}} \over 5}} , and α 5 = 1 α 0 + 4 α 1 5 {\textstyle \alpha _{5}={{1\alpha _{0}+4\alpha _{1}} \over 5}} with α 6 = 0 {\displaystyle \alpha _{6}=0} and α 7 = 255 {\displaystyle \alpha _{7}=255} . The lookup table
155-528: 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
186-922: A four-byte ID. The IFF specification explicitly mentions that the origins of the FourCC idea lie with Apple. This IFF was adopted by a number of developers including Apple for AIFF files and Microsoft for RIFF files (which were used as the basis for the AVI and WAV file formats). Apple referred to many of these codes as OSTypes . Microsoft and Windows developers refer to their four-byte identifiers as FourCCs or Four-Character Codes . FourCC codes were also adopted by Microsoft to identify data formats used in DirectX , specifically within DirectShow and DirectX Graphics. Since Mac OS X Panther , OSType signatures are one of several sources that may be examined to determine
217-476: A human-readable way (e.g., " mp4a "). Some FourCCs however, do contain non-printable characters, and are not human-readable without special formatting for display; for example, 10bit Y'CbCr 4:2:2 video can have a FourCC of ('Y', '3', 10, 10) which ffmpeg displays as rawvideo (Y3[10] [10] / 0x0A0A3359), yuv422p10le . Four-byte identifiers are useful because they can be made up of four human-readable characters with mnemonic qualities, while still fitting in
248-469: A string. Many C compilers, including GCC, define a multi-character literal behavior of right-aligning to the least significant byte, so that '1234' becomes 0x3 1 3 2 3 3 3 4 in ASCII. This is the conventional way of writing FourCC codes used by Mac OS programmers for OSType. ( Classic Mac OS was exclusively big-endian.) On little-endian machines, a byte-swap on the value is required to make
279-453: A two-byte identifier, usually written in hexadecimal (such as 0055 for MP3 ). In QuickTime files, these two-byte identifiers are prefixed with the letters "ms" to form a four-character code. RealMedia files also use four-character codes, however, the actual codes used differ from those found in AVI or QuickTime files. Other file formats that make important use of the four-byte ID concept are
310-411: A value of 3 corresponding to c 3 {\displaystyle c_{3}} . 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
341-486: 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 . Like many modern image compression algorithms, S3TC only specifies the method used to decompress images, allowing implementers to design
SECTION 10
#1732801610700372-461: Is also known as QuickTime Video , by its FourCC RPZA and the name Road Pizza . (The codename "Road Pizza" is a reference to the idea that "when you run over an animal, you're basically compressing it on the freeway". ) When used in the AVI container , the FourCC AZPR is also used. The bit-stream format of Apple Video has been reverse-engineered and a decoder has been implemented in
403-626: Is then consulted to determine the alpha value for each pixel, with a value of 0 corresponding to α 0 {\displaystyle \alpha _{0}} and a value of 7 corresponding to α 7 {\displaystyle \alpha _{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. BC4 and BC5 (Block Compression 4 and 5) are added in Direct3D 10. They reuse
434-492: 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. The lookup table is then consulted to determine the color value for each pixel, with a value of 0 corresponding to c 0 {\displaystyle c_{0}} and
465-526: The Amiga / Electronic Arts Interchange File Format and derivatives. The idea was later reused to identify compressed data types in QuickTime and DirectShow . In 1984, the earliest version of a Macintosh OS, System 1 , was released. It used the single-level Macintosh File System with metadata fields including file types , creator (application) information , and forks to store additional resources . It
496-627: The Standard MIDI File (SMF) format, the PNG image file format, the 3DS (3D Studio Max) mesh file format and the ICC profile format. Four-character codes are also used in applications other than file formats, for example: Other uses for OSTypes include: Apple Video Apple Video is a lossy video compression and decompression algorithm ( codec ) developed by Apple Inc. and first released as part of QuickTime 1.0 in 1991. The codec
527-394: The original Apple Video codec . Otherwise, if c 0 ≤ c 1 {\displaystyle c_{0}\leq c_{1}} , then c 2 = 1 2 c 0 + 1 2 c 1 {\textstyle c_{2}={1 \over 2}c_{0}+{1 \over 2}c_{1}} and c 3 {\displaystyle c_{3}}
558-813: 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 {\displaystyle c_{0}} and c 1 {\displaystyle 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. 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
589-593: 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). crunch is another tool that performs RDO and optionally further re-encoding. In 2021, Microsoft produced
620-634: The alpha channel encoding found in DXT4/5 (BC3). BC6H (sometimes BC6) and BC7 (Block Compression 6H and 7) are added in Direct3D 11. BC6H and BC7 have a much more complex algorithm with a selection of encoding modes. The quality is much better as a result. These two modes are also specified much more exactly, with ranges of accepted deviation. Earlier BCn modes decode slightly differently among GPU vendors. BCn textures can be further compressed for on-disk storage and distribution ( texture supercompression ). An application would decompress this extra layer and send
651-500: The bit-stream. The four colors can be interpreted as lying equidistantly spaced on a line segment in the three-dimensional vector space with the three components red, green, and blue. The end-points of this line are written in the bit-stream. A similar color-interpolation scheme is used in S3 Texture Compression . Interpreted as vector quantization , a three-dimensional vector with the components red, green, and blue
SECTION 20
#1732801610700682-1007: 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 c 0 {\displaystyle c_{0}} and c 1 {\displaystyle c_{1}} , and a 4×4 two-bit lookup table. If c 0 > c 1 {\displaystyle c_{0}>c_{1}} (compare these colors by interpreting them as two 16-bit unsigned numbers), then two other colors are calculated, such that for each component, c 2 = 2 3 c 0 + 1 3 c 1 {\textstyle c_{2}={2 \over 3}c_{0}+{1 \over 3}c_{1}} and c 3 = 1 3 c 0 + 2 3 c 1 {\textstyle c_{3}={1 \over 3}c_{0}+{2 \over 3}c_{1}} . This mode operates similarly to mode 0xC0 of
713-399: 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
744-418: The current frame. Runs of skip blocks are coded in a run-length encoding scheme, enabling a high compression ratio in static areas of the picture. In single color mode, all pixels in a block are decoded in the same color. This can be interpreted as a palette with a single color. In four color mode, each pixel in a block is decoded as one of four colors which are specified in a palette. To select one of
775-448: The four entries, 2 bits per pixel are written to the bit-stream. The same palette is used for a run of length between one and 32 blocks. Of the four colors, two are explicitly written to the bit-stream, while the other two are calculated at the decoder by linear interpolation in the RGB colorspace using the following equations: where color0 and color3 are the two colors which are written in
806-411: The four-byte memory space typically allocated for integers in 32-bit systems (although endian issues may make them less readable). Thus, the codes can be used efficiently in program code as integers, as well as giving cues in binary data streams when inspected. FourCC is written in big endian relative to the underlying ASCII character sequence, so that it appears in the correct byte order when read as
837-401: The image domain without motion compensation, decoding is much faster than MPEG -style codecs which use motion compensation and perform coding in a transform domain. As a tradeoff, the compression performance of Apple Video is lower. The skip mode realizes conditional replenishment. If a block is coded in skip mode, the content of the block at same location in the previous frame is copied to
868-544: The macOS command line tools GetFileInfo and SetFile which are installed as part of the developer tools into /Developer/Tools , or the ResEdit utility available for older Macs. The byte sequence is usually restricted to ASCII printable characters , with space characters reserved for padding shorter sequences. Case sensitivity is preserved, unlike in file extensions . FourCCs are sometimes encoded in hexadecimal (e.g., "0x31637661" for ' avc1 ') and sometimes encoded in
899-491: The projects XAnim and Libavcodec . The codec operates on 4×4 blocks of pixels in the RGB colorspace. Each frame is segmented into 4×4 blocks in raster-scan order. Each block is coded in one of four coding modes: skip, single color, four color, or 16 color. Colors are represented by 16 bits with a bit-depth of 5 bit for each of the three components red, green, and blue, a format known as RGB555 . Because Apple Video operates in
930-566: The result correct. Taking the avc1 example from above: although the literal 'avc1' already converts to the integer value 0x61766331 , a little-endian machine would have reversed the byte order and stored the value as 31 63 76 61 . To yield the correct byte sequence 61 76 63 31 , the pre-swapped value 0x31637661 is used. One of the most well-known uses of FourCCs is to identify the video codec or video coding format in AVI files. Common identifiers include DIVX , XVID , and H264 . For audio coding formats , AVI and WAV files use
961-547: Was possible to change this information without changing the data itself, so that they could be interpreted differently. Identical codes were used throughout the system, as type tags for all kinds of data. In 1985, Electronic Arts introduced the Interchange File Format (IFF) meta-format (family of file formats), originally devised for use on the Amiga . These files consisted of a sequence of "chunks", which could contain arbitrary data, each chunk prefixed by