S3 Texture Compression

S3 Texture Compression (S3TC, manchmal auch DXTn oder DXTC) ist ein ursprünglich für die Savage 3D entwickeltes Texturkomprimierungssystem von S3 Graphics, das im Jahre 1997 zum Patent angemeldet wurde.^[1] Es eignet sich im Gegensatz zu Bildkompressionsalgorithmen wie JPEG für hardwarebeschleunigte Computergrafik, da es eine feste Datenkompressionsrate besitzt und nur einen Speicherzugriff pro Texel benötigt. Durch die Aufnahme in DirectX 6.0 wurde S3TC schnell herstellerübergreifend akzeptiert und ist heute der vorherrschende Standard. Die DXT-Formate werden in OpenGL als Extension unterstützt.

Übersicht[Bearbeiten | Quelltext bearbeiten]

S3TC besteht aus fünf Formaten, die nach den ihnen in DirectX zugewiesenen FourCC-Identifikation als DXT1 bis DXT5 benannt wurden und sich in der Handhabung des Alphakanals unterscheiden. DXT2 und DXT4 werden kaum verwendet und sind im Gegensatz zu den anderen drei Formaten auch nicht Teil der OpenGL-Erweiterung für S3TC.

Wie jeder andere verlustbehaftete Kompressionsalgorithmus versucht S3TC sichtbare Artefakte trotz hoher Datenpackrate zu minimieren. So kann bei gleichem Speicherbedarf eine Textur mit deutlich höherer Auflösung verwendet werden, was insgesamt zu einem besseren Ergebnis führt. Wie die meisten modernen Algorithmen zur Bildkompression legt S3TC nur fest, wie die Daten entpackt werden, und lässt damit Spielraum für verschiedene Ansätze bei der Kompression. Trotzdem fallen Lizenzgebühren an, da die grundlegende Implementation von einem Patent abgedeckt wird.

Mit Direct3D 10 wurden die fünf DXT-Stufen als veraltet (deprecated) eingestuft. Der Unterschied zwischen vorher und nachher multiplizierten Alpha-Werten wird nicht mehr gemacht. Aus DXT1 wird BC1, aus DXT2 und DXT3 wird BC2, aus DXT4 und DXT5 wird BC3.^[2]

Funktionsprinzip[Bearbeiten | Quelltext bearbeiten]

Insgesamt wurden fünf Algorithmen entwickelt, die auf demselben Prinzip basieren, aber für verschiedene Typen von Bilddaten ausgelegt sind. Die Textur wird zunächst in 4×4-Texel-Blöcke zerlegt. Aus den 16 Farbwerten werden zwei 16 Bit RGB-565-Farben berechnet. Die einzelnen Algorithmen berechnen aus diesen beiden weitere Farbwerte und speichern sie in einer Lookup-Tabelle. Wie in einer Grafik mit Farbpalette wird für jedes Texel nur der Index des am besten passenden Farbwertes in der Tabelle gespeichert und nicht die Farbe des Texels selbst. Die Einträge dort können mit nur wenigen Bits adressiert werden, so dass sich bei 32 Bit RGBA-Texturen Kompressionsraten von 8:1 bei DXT1 und 4:1 bei allen anderen Codecs ergeben.

DXT1[Bearbeiten | Quelltext bearbeiten]

Für jeden 4×4 Textur-Block werden neben den beiden 16-Bit-Farbwerten pro Texel ein 2-Bit-Index berechnet. Insgesamt werden also 64 Bit pro Block benötigt, und die Lookup-Tabelle kann maximal vier Einträge enthalten.

Falls der erste Farbwert größer als der zweite ist, lauten die beiden anderen:

${\displaystyle c_{2}={2 \over 3}c_{0}+{1 \over 3}c_{1}.}$

${\displaystyle c_{3}={1 \over 3}c_{0}+{2 \over 3}c_{1}.}$

Ansonsten gilt:

${\displaystyle c_{2}={1 \over 2}c_{0}+{1 \over 2}c_{1}}$

${\displaystyle c_{3}=\!\ transparent.}$

DXT1 komprimiert im Vergleich zu den anderen Algorithmen doppelt so stark, da hier keine Alpha-Werte gespeichert werden.

DXT3[Bearbeiten | Quelltext bearbeiten]

DXT3 komprimiert die Farbwerte wie DXT1, jedoch wird nicht zwischen den beiden Schemata unterschieden, sondern immer die erste Variante mit vier opaken Farben verwendet, Transparenz wird durch einen zusätzlichen 4-Bit-Alphakanal ermöglicht. Insgesamt werden 128 Bit pro Block benötigt. DXT3 eignet sich vor allem für Texturen mit harten Übergängen zwischen transparenten und opaken Bereichen.

DXT5[Bearbeiten | Quelltext bearbeiten]

DXT5 komprimiert die Farbwerte wie DXT1. Es werden zwei 8-Bit-Alphawerte gespeichert sowie pro Pixel ein 3-Bit-Wert, der zum Interpolieren zwischen den Alphawerten dient. Falls der erste Alphawert größer als der zweite ist, werden durch lineares Interpolieren acht Alphawerte erhalten. Ansonsten werden nur sechs Alphawerte durch Interpolieren erzeugt, während die anderen beiden 0 und 1 sind. Es werden 128 Bit pro Block benötigt.

Kritik[Bearbeiten | Quelltext bearbeiten]

In der Praxis haben sich vor allem Cartoon-artige Zeichnungen und Normal Maps als problematisch erwiesen. Der von ATI entwickelte 3Dc-Algorithmus setzt auf S3TC auf, komprimiert Normals Maps aber deutlich effizienter. Auch Id Software beschäftigte sich bei der Entwicklung von Doom 3 mit dem Thema. Die Programmierer umgingen das Problem zumindest teilweise, indem sie den roten Farbkanal mit dem Alpha-Kanal vor und nach der Kompression vertauschten.^[3]

Um S3TC mit Mesa 3D nutzen zu können, muss die Bibliothek libtxc_dxtn installiert sein.^[4]

Weblinks[Bearbeiten | Quelltext bearbeiten]

• Texture compression survey (englisch; PDF-Datei; 1,35 MB)
• Folien eines Vortrags über Texturkomprimierung (PDF-Datei; 1,36 MB)
• GL_EXT_texture_compression_s3tc OpenGL Erweiterung (englisch)

Einzelnachweise[Bearbeiten | Quelltext bearbeiten]

1. ↑ Patent EP1034505B1: System und Verfrahren für blockbasierte Bildkompression mit fester Rate unter Verwendung von abgeleiteten Pixelwerten. Angemeldet am 28. September 1998, veröffentlicht am 25. November 2009, Anmelder: S3 Graphics Co Ltd, Erfinder: Konstantine Iourcha et al.‌
2. ↑ Deprecated Features (Direct3D 10)
3. ↑ DOOM 3 Video Requirements
4. ↑ S3TC with DRI drivers