Jump to content
 







Main menu
   


Navigation  



Main page
Contents
Current events
Random article
About Wikipedia
Contact us
Donate
 




Contribute  



Help
Learn to edit
Community portal
Recent changes
Upload file
 








Search  

































Create account

Log in
 









Create account
 Log in
 




Pages for logged out editors learn more  



Contributions
Talk
 



















Contents

   



(Top)
 


1 Patent  





2 Codecs  





3 DXT1  





4 DXT2 and DXT3  





5 DXT4 and DXT5  





6 Further variants  



6.1  BC4 and BC5  





6.2  BC6H and BC7  







7 S3TC format comparison  





8 Data preconditioning  





9 See also  





10 References  





11 External links  














S3 Texture Compression






Deutsch

Português
Русский
 

Edit links
 









Article
Talk
 

















Read
Edit
View history
 








Tools
   


Actions  



Read
Edit
View history
 




General  



What links here
Related changes
Upload file
Special pages
Permanent link
Page information
Cite this page
Get shortened URL
Download QR code
Wikidata item
 




Print/export  



Download as PDF
Printable version
 
















Appearance
   

 






From Wikipedia, the free encyclopedia
 

(Redirected from S3TC)

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. 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,[4] while implementation approaches which tried to avoid the patented parts existed.[5]

Patent[edit]

Some (e.g. US 5956431 A) of the multiple USPTO patents on S3 Texture Compression expired on October 2, 2017.[6] At least one continuation patent, US6,775,417, however had a 165-day extension. This continuation patent expired on March 16, 2018.

Codecs[edit]

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[edit]

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 and , and a 4×4 two-bit lookup table.

If(compare these colors by interpreting them as two 16-bit unsigned numbers), then two other colors are calculated, such that for each component, and . This mode operates similarly to mode 0xC0 of the original Apple Video codec.[8]

Otherwise, if , then and 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 and a value of 3 corresponding to .

DXT2 and DXT3[edit]

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 and ).

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[edit]

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).

If, then six other alpha values are calculated, such that , , , , , and .

Otherwise, if , four other alpha values are calculated such that , , , and with and .

The lookup table is then consulted to determine the alpha value for each pixel, with a value of 0 corresponding to and a value of 7 corresponding to . 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.

Further variants[edit]

BC4 and BC5[edit]

BC4 and BC5 (Block Compression 4 and 5) are added in Direct3D 10. They reuse the alpha channel encoding found in DXT4/5 (BC3).[9]

BC6H and BC7[edit]

BC6H (sometimes BC6) and BC7 (Block Compression 6H and 7) are added in Direct3D 11.[9]

BC6H and BC7 have a much more complex algorithm with a selection of encoding modes. The quality is much better as a result.[9] These two modes are also specified much more exactly, with ranges of accepted deviation. Earlier BCn modes decode slightly differently among GPU vendors.[10]

S3TC format comparison[edit]

FOURCC DX 10/11 name Description Alpha premultiplied? Compression ratio Texture type
DXT1 BC1 1-bit alpha / opaque Yes 6:1 (for 24-bit source image) Simple non-alpha
DXT2 BC2 Explicit alpha Yes 4:1 Sharp alpha
DXT3 BC2 Explicit alpha No 4:1 Sharp alpha
DXT4 BC3 Interpolated alpha Yes 4:1 Gradient alpha
DXT5 BC3 Interpolated alpha No 4:1 Gradient alpha
BC4 Interpolated greyscale 2:1 Gradient
BC5 Interpolated two-channel 2:1 Gradient
BC6H Interpolated HDR (no alpha) 6:1 Gradient
BC7 Interpolated alpha ? 4:1 Gradient

Data preconditioning[edit]

BCn textures can be further compressed for on-disk storage and distribution (texture supercompression). 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.[13]

See also[edit]

References[edit]

  1. ^ US 5956431  "Fixed-rate block-based image compression with inferred pixel values"
  • ^ US 5956431, Iourcha, Konstantine I.; Nayak, Krishna S. & Hong, Zhou, "System and method for fixed-rate block-based image compression with inferred pixel values", published Sep 21, 1999 
  • ^ "1990 IEEE Color Cell Compression Paper". Ieeexplore.ieee.org. doi:10.1109/TENCON.1990.152671. S2CID 62015990. {{cite journal}}: Cite journal requires |journal= (help)
  • ^ "S3TC situation on official DRI information page". Dri.freedesktop.org. Archived from the original on 2012-01-19. Retrieved 2012-01-25.
  • ^ S2TC: A Possible Workaround For The S3TC Patent Situation Archived 2016-05-13 at the Wayback Machineonphoronix
  • ^ Yates, Tom (2017-02-15). "This is why I drink: a discussion of Fedora's legal state". LWN.net. Archived from the original on 2017-03-01. Retrieved 2017-02-16. ... The patent on S3 texture compression expires on October 2, 2017, so Steam games might work better on Fedora after that date. ...
  • ^ Duffy, Robert (July 27, 2004). "DOOM 3 Video Requirements". Gamershell.com. Archived from the original on January 3, 2008. Retrieved 2012-01-25.
  • ^ Togni, Roberto, et al. "Apple RPZA Archived 2017-07-04 at the Wayback Machine". MultimediaWiki.
  • ^ a b c Reed, Nathan. "Understanding BCn Texture Compression Formats". Nathan Reed’s coding blog. Archived from the original on 2020-11-09. Retrieved 2020-09-01.
  • ^ a b c d Giesen, Fabian “ryg” (4 October 2021). "GPU BCn decoding". The ryg blog. Archived from the original on 24 July 2023. Retrieved 24 July 2023.
  • ^ "Oodle Texture Compression". www.radgametools.com. Archived from the original on 2023-03-18. Retrieved 2023-04-03. Open source part mentioned: bc7enc_rdo Archived 2021-02-02 at the Wayback Machine
  • ^ "crunch open source texture compression library". GitHub. Archived from the original on 2016-09-09. Retrieved 2016-09-13.
  • ^ "DirectStorage Overview - Microsoft Game Development Kit". 16 March 2023. Archived from the original on 3 August 2023. Retrieved 3 August 2023.
  • External links[edit]


    Retrieved from "https://en.wikipedia.org/w/index.php?title=S3_Texture_Compression&oldid=1230021436"

    Categories: 
    3D computer graphics
    Lossy compression algorithms
    Texture compression
    Hidden categories: 
    CS1 errors: missing periodical
    Webarchive template wayback links
    Articles with short description
    Short description is different from Wikidata
     



    This page was last edited on 20 June 2024, at 03:10 (UTC).

    Text is available under the Creative Commons Attribution-ShareAlike License 4.0; additional terms may apply. By using this site, you agree to the Terms of Use and Privacy Policy. Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization.



    Privacy policy

    About Wikipedia

    Disclaimers

    Contact Wikipedia

    Code of Conduct

    Developers

    Statistics

    Cookie statement

    Mobile view



    Wikimedia Foundation
    Powered by MediaWiki