Der lange Weg zum HDR-Rendering

1. Januar 2006 / von aths / Seite 2 von 3

   Was ist Licht, was ist Farbe?

Was wir als Farbe wahrnehmen, ist Licht, also ein Ausschnitt aus dem elektromagnetischen Spektrum. Die "echte" Farbe ist das Spektrum des gesamten sichtbaren Lichtes. Im RGB-Modell, was in GPUs genutzt wird, vereinfacht man das Spektrum auf gerade mal drei Werte: Rot-, Grün- und Blau-Anteil. Licht, welches etwas kurzwelliger als blau ist, erscheint uns violett – doch kurzwelliger als blau geht es im RGB-Modell nicht. Bestimmte Farben muss man anderweitig zusammenmixen und hierbei ausnutzen, dass sich das Auge ganz gut täuschen lässt. Einige Farben sind im RGB-Modell gar nicht exakt darstellbar.

Für den Menschen eher verständlich sind Farbmodelle wie HSL, welches die Farbe mit ihrem Farbton (Hue), der Sättigung (Saturdation) und der Helligkeit (Lightness) beschreibt. Im Prinzip benötigen wir für HDR-Lighting im HSL-Modell eine hohe Dynamik nur für den L-Kanal. Im RGB-Raum müssen, um eine sehr hohe Helligkeit zu beschreiben, alle drei Komponenten große Zahlenwerte annehmen.

Speziell dafür ist zum Beispiel das RGBE-Modell geschaffen worden, wo alle Komponenten um den gemeinsamen Exponenten E skaliert werden. Doch Grafikkarten sind, was Farben angeht, nur für direkte RGB-Verarbeitung optimiert. Außerdem wollen wir ja Einheitlichkeit gewährleisten. Da man im Pixelshader nicht nur Farben, sondern beliebige Daten verarbeitet können möchte, muss die hohe Dynamik für alle Komponenten geboten werden.

"Farbe" ist zunächst ein subjektiver Eindruck, der sich ergibt, wenn Licht aufs Auge fällt. Um Farbe objektiv (oder sagen wir besser, mathematisch verwertbar) zu beschreiben, nutzt man Farbraum-Modelle, die jedoch alle bestimmte Stärken und Schwächen haben. Das RGB-Modell bietet die direkte Anzeigemöglichkeit mit RGB-Elementen als ausschlaggebenden Vorteil. Um Farbton-, Farbsättigungs- oder Helligkeitsänderungen vorzunehmen, müssen jedoch immer alle drei RGB-Kanäle in die Rechnung mit einbezogen werden. Das ist zunächst ein Nachteil. Doch im Zuge der möglichst allgemeinverwendbaren Pixelshader-Technik muss diese sowieso darauf ausgelegt sein, pro Takt eine Operation auf alle Kanäle gleichzeitig auszuführen.

   Die Berechnung der Dynamik

"HDR" alleine sagt nichts. HDR-was? Wenn Leute von "HDR" sprechen, meinen sie oft HDR-Rendering - oder nicht einmal das, sondern nur den Glow-Effekt, der sich auch ohne HDR-Rendering realisieren lässt. Es gibt auch HDR-Imaging und es könnte bald auch HDR-Monitore geben.

Dazu ein kurzer Absatz: Um als Hintergrund Papier zu simulieren, nehmen Windows-Applikationen als Hintergrundfarbe oft Weiß – denn (gebleichtes) Papier ist weiß. Das verhindert leider, dass wir den Kontrastumfang des Monitors ausnutzen können. Um in die Augen nicht ständig gleißendes Licht reindonnern zu lassen, regeln wir die Gesamthelligkeit des Gerätes herunter. Damit kann kein glänzendes Weiß mehr dargestellt werden.

Viel sinnvoller wäre es, wenn der Hintergrund von Applikationen hellgrau ist, welches zunächst wie fast weiß wirken mag – und man dennoch ein helleres Weiß darstellen kann. Weiß ist eben nicht gleich weiß – ob wir eine unbunte Farbe schon als weiß oder noch als grau emfinden, ist eine Frage der Umgebungsbedingungen. Im Dunklen wirkt selbst Dunkelgrau schon fast weiß, wobei die gleiche absolute Helligkeit bei Tageslicht beinahe schwarz erscheint. Eine nur ein Pixel starke dunkelgraue Linie, welche von Weiß umgeben ist, sieht für uns schwarz aus – während wir bei einem großen Rechteck der gleichen Helligkeit den Unterschied zu schwarz sofort sehen.

All die tollen Kontraste von Geräten von etwa 1:1000 bringen nichts, wenn man das Gerät in der Helligkeit dämpft – was man leider oft tun muss, da bedenkenlos maximal helles Weiß als Hintergrundfarbe gewählt wird. "HDR-Monitore" würden "100% Weiß" dunkler darstellen, als "überhelles" Weiß. Wie man die Helligkeit für Reinweiß festlegt, ist Auslegungssache. Klar ist, dass man einen Monitor mit Kontrastwerten von ca. 1:1000 nicht laufend mit dem hellsten Weiß, was er anzeigen kann, betreiben sollte – entweder ist es für das Auge zu hell und stört somit, oder wir müssen das Gerät herunterregeln und senken damit den Kontrastumfang.

Für HDR-Imaging werden Bilder in besseren Formaten als Truecolor gespeichert und verarbeitet. Bilder von speziellen HDR-Kameras erlauben zum Beispiel nachträgliche Belichtungskorrektur auf einem ganz anderen Level, als Fotonachbearbeitungsprogramme bei Truecolor-Dateien bieten.

Wenn wir über die HDR-Definition sprechen, beziehen wir uns ausdrücklich nur auf Farben. Zunächst muss geklärt werden, wie man die Dynamik berechnet. Dazu dividiert man den größten darstellbaren Wert durch kleinsten positiven Wert ungleich Null. Das traditionelle 8-Bit-Format für ein Farbkanal stellt den Bereich von 0 bis 1 in 256 Stufen dar. Der kleinste Wert ungleich Null ist 1/255. Die Dynamik ist demzufolge 1 / (1/255) = 255.

Um mit kleineren Zahlen hantieren zu können, die sich zudem leichter verrechnen lassen, wird oft ein logarithmisches Format genommen. Wir nehmen den Logarithmus zur Basis 10, und runden auf eine Nachkommastelle: log₁₀ 255=2,4. Um die logarithmische Darstellung deutlich zu machen, bezeichnen wir die Dynamik als 2,4 Bel, oder 24 Dezibel, dB.

Diese Angabe ist bitte nicht mit der dB-Angabe für Schalldruck zu verwechseln, und ebensowenig mit anderen dB-Angaben zu vergleichen. Eine Audio-CD bietet laut gängiger Definition mit 16 Bit linearer Quantisierung eine Dynamik von bis zu 96 dB - 16 Bit linear entsprechen aber nur 48 dB nach unserer Rechnung. Der Grund: dB-Leistungswerte werden mit 10 multipliziert, da Dezibel ja Zehntel Bel angeben. Wenn man Spannungswerte wie bei der Audio-CD vergleicht, trägt man der Tatsache Rechnung, dass elektrische Leistung proportional zum Quadrat der Spannung ist. Multipliziert man den Logarithmus des Spannungsverhältnisses mit 20, wird dank Logarithmus Potenz (hoch 2) zum Faktor (mal 2). Wir brauchen die dB-Maßeinheit aber nicht zum Vergleich mit anderen dB-Angaben, sondern nur um die Dynamik in Bezug auf Helligkeiten mit "handlichen" Zahlen beschreiben zu können. Unsere dB-Vergleiche für High Dynamic Range gelten also nur innerhalb unseres Artikels.

Das ist sehr wenig. Um das 8-Bit-Format besser auszunutzen, wurden diverse Standards eingeführt, durchgesetzt hat sich sRGB. Die Umrechnungsformel in lineares RGB ist sehr kompliziert, doch man kann die sRGB-Kennlinie sehr gut mit der Gamma-Funktion 2,2 annähern. Ein guter Monitor ist darauf geeicht. Das heißt zum Beispiel, dass mittelgrau nicht mit den 8-Bit-RGB-Werten (128, 128, 128) dargestellt wird. Halbgrau entspricht im sRGB-Format (186, 186, 186) – es gibt also 186 Werte für Darstellungen kleiner als halbhell und nur 70 für Werte größer als halbhell.

Kleine Werte feiner abzustufen bringt auch für die Dynamik was, da der größte Wert mit dem kleinsten verglichen wird. Leider werden bei Texturfilterung die Farben immer als lineares RGB interpretiert. Das führt zu diversen Grafikproblemen, welche auch die Anfälligkeit für Texturflimmern verstärken konnen. Außerdem wird "MIP-Banding", also der plötzliche Detailstufenübergang bei bilinearer Filterung, deutlicher sichtbar.

Man könnte darauf pochen, dass 8-Bit-sRGB-Texturen endlich korrekt behandelt werden sollen. Oder man nutzt ein Format, welches kleine Werte (zu Lasten der großen Werte) ohnehin feiner abstufen kann: Die Gleitkomma-Darstellung. Der Vorteil ist dann die wieder die einheitliche Entwicklung: Nicht nur für Farben, sondern für fast alle Daten ist die Gleitkommadarstellung einer Festkommadarstellung vorzuziehen.

   Wozu HDR-Rendering bei heutigen Monitoren?

Ein Wiedergabegerät mit einem Kontrastverhältnis von 1:1000 bietet eine Dynamik von 30 dB. Das RGB-Format, linear interpretiert, hat nur 24 dB – ist der 1:1000-Kontrast prinzipiell nur theoretisch? Nein, denn die RGB-Werte werden vom Display meistens nichtlinear interpretiert. Wie schon angesprochen, hat sich hier der sRGB-Standard einigermaßen durchgesetzt, welcher sogar noch mehr als 30 dB Dynamik bietet. Doch auch sRGB ist als "niedrige" Dynamik, als LDR-Format einzustufen. Deshalb: Wozu HDR-Rendering, wenn man nur einen LDR-Monitor hat?

Dies lässt sich am besten mit dem Vergleich zu einer Digitalkamera erklären. Dessen Ausgabeformat, egal ob JPEG oder TIFF, wird in der Regel nur als Truecolor-RGB-Bild angezeigt. Ohne Blende und Belichtungszeit einzustellen (was heute in der Regel die Automatik macht), könnte man den Fotoapparat nur unter genau definierten, sehr eng begrenzten Lichtbedingungen nutzen. Ansonsten wäre der Großteil des Fotos rein schwarz oder rein weiß.

Beim LDR-Rendering ist sozusagen Blende und Belichtungszeit immer dieselbe, egal ob man unter der prallen Sonne oder im schattigen Wald ist. Mit HDR-Rendering kann das Bild zunächst mit seinen tatsächlichen Helligkeiten berechnet werden, anschließend wird es so auf einen Dynamikbereich komprimiert, dass wir nach Möglichkeit sowohl dunkle als auch helle Gebiete noch gut erkennen. Diese Komprimierung muss an das jeweilige Bild angepasst sein. Die Gruppe solcher Verfahren wird "Tonemapping" genannt. Tonemapping ist ein Sammelbegriff für diverse mathematische Ansätze der (in der Regel nichtlinearen) Dynamikkompression.

Natürlich könnte man Truecolor so skalieren, der kleinste RGB-Wert für "im Dunklen gerade noch so erkennbares Grau" und der größte für "direkter Blick in die Sonne" steht. Über diesen gewaltigen Bereich nur 256 unterschiedliche Stufen zu haben, ist aber viel zu wenig. Hohe Dynamik ist, wie schon angesprochen, nicht damit erreicht, dass der größte darstellbare Wert sehr groß ist, sondern dass man sowohl sehr kleine als auch sehr große Werte zur Verfügung hat.

Auch beim 16-Bit-Rendering im Highcolor-Format mit 5 Bit für R und B und 6 Bit für G kann man – wie im Truecolor-Format – Helligkeiten von 0% bis 100% darstellen. Doch hat man bei aufwändigen Grafikeffekten schnell Colorbanding: Die Anzahl der möglichen Farb- und vor allem Helligkeitsstufen reicht nicht aus, um feine Helligkeitsunterschiede zu berücksichtigen. Entsprechende Rundungsfehler werden sehr schnell sichtbar, man verliert also an Details. Mit 32-Bit-Rendering (8 Bit je für R, G, B und weiteren 8 ungenutzen oder für andere Zwecke benötigte Bits) kann auch auch heute schon Colorbanding bekommen. Dies sieht man zum Beispiel in Quake III, wenn Nebel simuliert wird, in Warcraft 3, wenn man noch unerforschte Gebiete der Karte betrachtet, aber auch in Max Payne, wenn man in dunkle Ecken geht.

Das heißt, nicht nur die Dynamik spielt bei der Frage, warum HDR-Rendering nützlich ist, eine Rolle. Wir brauchen zusätzlich mehr Bits für mehr Zwischenwerte. Um für die Effekte zukünftiger Spiele gerüstet zu sein, reicht 32-Bit-Rendering mit 24-Bit-Farbgenauigkeit im Framebuffer zur Vermeidung von Colorbanding nicht immer aus. Die Radeon X1800 (R520) bietet neben 24 Bit Farbe auch einen Framebuffer mit 30 Bit Farbe – sogar mit Multisampling, was der R300-Chip (Radeon 9700) mit seiner 30-Bit-Farbe noch nicht beherrscht.

Damit könnte man das Colorbanding in den genannten Beispielen schon deutlich reduzieren. Doch das wäre nur ein kleiner Zwischenschritt: Die Dynamik steigt von 24 auf 30 dB. Der Sprung vom Highcolor-Rendering auf Truecolor-Rendering war immerhin (normalisiert auf die Helligkeit) von 17 auf 24 dB. Lange Rede, kurzer Sinn: Wir brauchen gleich einen 64-Bit-Framebuffer, um Farbe mit mindestens 48 Bit, also 16 Bit pro RGB-Kanal, speichern zu können.

Mit 64-Bit-Rendering lassen sich viele Probleme lösen. Die Bitstellen haben wir nun, aber welches Datenformat wäre zu empfehlen? Für die Dynamik sind Gleitkomma-Formate günstiger als Festkomma-Formate, weshalb man zukünftig im gleichen Zuge auf die aufwändigen Gleitkomma-Units setzen wird. Seit NV40 (GeForce 6800) bzw. R520 (Radeon X1800) werden entsprechende Render-Target (mit Blending-Operationen) unterstützt. Dabei ist das viel aufwändiger, als würde man Festkomma-Daten bieten. Warum dieser Aufwand?

Der durschnittliche Rundungsfehler im Festpunkt-Format ist, absolut gesehen, immer gleich groß. Doch stört er bei kleinen Zahlen viel mehr, da die relative Abweichung dann sehr groß ist. Im Gleitkomma-Format ist der durchschnittliche relative Rundungsfehler viel gleichmäßiger verteilt. Damit wird auch das durch die unvermeidlichen Rundungsfehler hervorgerufene Rauschen gleichmäßig verteilt und tritt nicht etwa nur im Dunklen, dort aber besonders krass, zutage (einen ähnlichen Effekt kann man auch bei Digitalkameras beobachten: Hellt man dunkle Bereiche der Fotos auf, sieht man starkes Rauschen). Durch die gleichmäßigere Verteilung des Rundungsfehlers beim HDR-Rendering mit Nutzung eines Gleitkomma-Formates steigt die Chance, dass das Rauschen, jetzt etwa gleich stark im Hellen wie im Dunklen, gänzlich unsichtbar wird.

Wird ein im HDR-Format vorliegendes Bild zur Monitor-Ausgabe auf LDR-Darstellung komprimiert, sinkt auch das während der Berechnung auftretende Rauschen. Das endgültige Bild ist um vieles besser als wenn es gleich als monitortaugliches LDR-Format errechnet würde. Deswegen bringt HDR-Rendering auch dann klare Vorteile, wenn man nur einen gewöhnlichen LDR-Monitor benutzt.