Wie stark komprimiert 3Dc?

15. Juni 2005 / von aths / Seite 5 von 7

   Wie stark komprimiert DXT1?

DXT1 kennt zwei Versionen, wir betrachten erst einmal nur diejenige, die rein für Bildtexturen gedacht ist. Genauer auf die Komprimierung von Bildtexturen einzugehen, ist für einen anderen Artikel geplant.

DXT1 speichert immer ganze Texelblöcke von 4x4 = 16 Texeln und benötigt dafür 64 Bit. Das entspricht also 4 Bit pro Texel. Die Datenrate nach der Komprimierung sagt jedoch noch nichts über die Komprimierungsrate. Um jene zu bestimmen, müssen wir DXT1 etwas näher untersuchen. Wie funktioniert die Dekomprimierung?

Der Block aus insgesamt 64 Bit besteht aus drei Unterblöcken à 16, 16 und 32 Bit. Die ersten beiden Bereiche à 16 Bit speichern je eine Referenzfarbe im RGB-Format. Und zwar ganz genau wie bei normalen 16-Bit-Texturen 5 Bit für Rot, 6 für Grün und 5 für Blau. Zwei Referenzfarben mit je 16 Bit belegen 32 Bit.

Danach folgt pro einzelnem Texel ein 2-Bit-Wert. Da 16 Texel gespeichert sind, umfasst der letzte Teil 2x16 = 32 Bit. Mit zwei Bit lassen sich vier Werte darstellen, aber es sind ja nur zwei Farben gespeichert! Für die Dekodierung werden die anderen beiden Farben rekonstruiert.

Zwischen zwei Referenzfarben wird interpoliert, um zwei zusätzliche Farben zu erhalten.

Damit ist klar: Kommen in dem 4x4-Block mindestens drei völlig unterschiedliche Farben vor, ist nach der Komprimierung mit starken Qualitätsverlusten zu rechnen. Denn es werden ja nur zwei einzelne Farben gespeichert, die anderen beiden ergeben sich aus linearer Interpolation. Es ist zum Beispiel nicht machbar, reines Rot, kräftiges Grün und sattes Blau gleichzeitig in einer solchen 4x4-Kachel zu kodieren.

Doch in der Regel ist es möglich, die beiden Referenzfarben so intelligent zu bestimmen, dass sich Bildtexturen oder gar echte Fotos komprimieren lassen, ohne dass die Qualitätsverluste stark auffallen. Hierfür haben wir drei Bilder mit MouseOver-Funktion vorbereitet (MouseOver-Effekt per Javascript, Alternativ-Variante: Klick öffnet jeweils beide Screenshots):

Vergleich: unkomprimiert und primitiv DXT1-komprimiert

Vergleich: primitiv DXT1-komprimiert und hochwertig DXT1-komprimiert

Vergleich: hochwertig DXT1-komprimiert und das Original

Bei der Komprimierung vergleichen wir eine selbst erdachte, noch unausgereifte Methode, sowie das Ergebnis von nvDXT aus den DDS-Utilities. Wie man sieht, lässt sich bei guter Komprimierung eine Qualität erreichen, die vom Original kaum zu unterscheiden ist. Der Helligkeitsunterschied fällt nur im direkten Vergleich mit dem Original auf. Würde die komprimierte Textur in einem Spiel eingesetzt, würde keiner sagen: "Diese Textur ist doch zu dunkel!" Allerdings ist Vorsicht geboten, wenn man komprimierte und "naturbelassene" Texturen nebeneinandersetzt. Update: Wir haben festgestellt, dass nicht die komprimierte Textur zu dunkel ist, sondern der verwendete Texturbetrachter falsch dekomprimiert: Er erweitert die 5- bzw. 6-Bit-Darstellung der Farbkanäle mit Nullen, anstatt die "most significant bits" in die freigewordenen Bitstellen zu kopieren.

Als Ausgangsmaterial wurden Bilder mit 24 Bit Farbtiefe verwendet. 24 Bit pro Pixel auf 4 Bit pro Pixel zu reduzieren, entspräche einer Komprimierungsrate von 6:1. Doch die beiden Referenzfarben, die gespeichert werden, sind im 16-Bit-Format. Deshalb muss zum Vergleich der Komprimierungsrate ein 16-Bit-Bild zugrunde gelegt werden. Von 16 Bit auf 4 hat man dann die 4:1-Komprimierung.

Die beiden Referenzfarben sollten vor der Interpolation auf 24 Bit hochgerechnet werden, damit wenigstens die Zwischenfarben feiner aufgelöst werden können. Man mag einwerfen, der Unterschied müsse doch minimal sein, aber GeForce1-4, welche bei DXT1 auch die beiden interpolierten Farben nur mit 16-Bit-Genauigkeit behandelte, zeigten entsprechendes Color Banding statt sanfter Farbübergänge.

Spätestens im Texturfilter wird dann sowieso mit 32 Bit (intern sogar mit mindestens 40 Bit) gerechnet, und zwar R, G, B und A mit je 8 (intern 10) Bit - obwohl man A (Alpha) gar nicht benötigt. Das Rechenwerk zum Filtern kann nun einmal 4 Kanäle gleichzeitig berechnen, man spart keine Zeit, wenn man A weglässt. Trotzdem würde keiner auf die Idee kommen, 16-Bit-Texturen als 32-Bit-Texturen zu bezeichnen, nur weil die Genauigkeit für die Filterrechnung "aufgeblasen" wird. Dass für hohe Qualität intern mit höherer Präzision gerechnet wird, ist selbstverständlich.

Diese Argumentation beziehen wir auch auf DXTC: Obwohl es für gute Qualität unbedingt erforderlich ist, die beiden Farbzwischenwerte genauer als mit 16 Bit möglich zu berechnen, sehen wir DXTC als 4:1 komprimierte 16-Bit-Textur und nicht als 6:1 komprimierte 24-Bit-Textur. Auch 16-Bit-Texturen werden in aller Regel aus 24-Bit-Farbwerten erstellt, ohne dass man die auf 16 Bit reduzierte Textur als 24-Bit-Textur bezeichnen würde.

In der Praxis gibt es übrigens keine echten 24-Bit-Texturen. Die Grafikkarte nutzt dann automatisch gleich 32-Bit-Texturen mit 8 Füllbits. Dies ist aus Gründen des effizienten Speichermanagments notwendig. Wer sich an die 2D-Ära erinnert, weiß, dass ein echter 24-Bit 2D-Farbmodus zwar Speicherplatz spart, aber langsamer ist als ein 32-Bit-Farbmodus, bei dem tatsächlich nur 24 Bit genutzt und pro Pixel noch 8 Füllbits übertragen werden. Trotzdem kommt man ja nicht auf die Idee, bei DXT1 von 8:1-Komprimierung zu sprechen, wenn man die auf 16 Bit Referenzfarben reduzierte 24-Bit-Textur als 32-Bit-Textur rechnet, nur weil die Hardware eben diese Füllbits verwendet.