DXTn

S3 Texture Compression (S3TC) (manchmal auch DXTn oder DXTC) ist ein ursprünglich für die Savage 3D entwickeltes Texturkomprimierungssystem von S3 Graphics^[1]. Es eignet sich im Gegensatz zu Bildkompressionsalgorithmen wie JPEG für hardware-beschleunigte Computergrafik, da es eine feste Datenkompressionsrate besitzt und nur einem Speicherzugriff pro Texel benötigt. Durch die Aufnahme in DirectX 6.0 wurde S3TC schnell herstellerübergreifend akzeptiert und ist heute der vorherrschende Standard. Eine Aufnahme in OpenGL 3 ist geplant.

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 besserem 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 auch da 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

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 4x4-Texel-Blöcke zerlegt. Aus den 16 Farbwerten werden zwei 16 Bit RGB565-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

Für jeden 4x4 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 4 Einträge enthalten.

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

$c_2 = {2 \over 3} c_0 + {1 \over 3} c_1.$

$c_3 = {1 \over 3} c_0 + {2 \over 3} c_1.$

Ansonsten gilt:

$c_2 = {1 \over 2} c_0 + {1 \over 2} c_1$

$c_3 = \!\ transparent.$

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

DXT3

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

DXT5 komprimiert die Farbwerte wie DXT1. Es werden zwei 8-Bit Alphawerte gespeichert, sowie pro Texel 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 8 Alphawerte erhalten. Ansonsten werden nur 6 Alphawerte durch Interpolieren erzeugt, während die anderen beiden 0 und 1 sind. Es werden 128 Bit pro Block benötigt.

Kritik

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

Referenzen

1. ↑ Patent US 5956431 "Fixed-rate block-based image compression with inferred pixel values"
2. ↑ http://msdn.microsoft.com/de-de/library/cc308047(VS.85).aspx Deprecated Features (Direct3D 10)
3. ↑ DOOM 3 Video Requirements [1]

Weblinks

• Texture compression survey (englisch)
• Folien eines Vortrags über Texturkomprimierung
• GL_EXT_texture_compression_s3tc OpenGL Erweiterung (englisch)