Die Farb-Pipeline von darktable

Die meisten Bild-Bearbeitungs-Anwendungen kommen aus den 1990ern und/oder erben einen 1990 Arbeitsablauf. Diese Anwendungen kodierten mit 8 bit vorzeichenlosen Ganzzahl, weil es Speicher- und Rechner-effizienter war. Jedoch, durch den Gebrauch eines Ganzzahl-Formates (was Rundungsfehler zur Folge hat) musste man ein “Gamma” hinzufügen (notwendigerweise eine Transfer-Funktion eine Potenz von 1/2.2 0der 1/2.4 um RGB Werte zu kodieren) und erhöhe die Bit-Tiefe in den Schatten, um Rundungsfehler zu reduzieren (Menschen sind sehr sensitiv für Schatten-Details). Die 8 bit Integer-Formate sind auch technisch auf den Bereich 1 - 255 limitiert. Alles, was außerhalb dieses Bereichs liegt, wird an der nächsten Grenze beschnitten.

Diese Bearbeitungen, die begrenzte RGB-Darstellungen und möglicherweise nicht-lineare Transformierungen nutzen, um RGB-Signale zu kodieren, werden “anzeigebezogen” genannt. Sie basieren auf der Annahme, dass ein Bild zum Anzeigen in einem frühen Schritt der Bearbeitungskette vorbereitet wurde, und eingebettet hart-kodierte Annahmen der RGB-Werte von Schwarz, Mittelgrau und Weiß enthält. Die meisten Bildverbearbeitungsalgorithmen, die für diese Bearbeitung genutzt werden, wurden um diese Annahmen herum abgestimmt. Zum Beispiel erwarten Überblendoperationen ein Mittelgrau von 50 % (oder 128 bei Integer-Kodierung).

Unglücklicherweise bricht die nicht-lineare Skalierung, welche für eine Integer-Kodierung nötig ist, die natürlichen Zusammenhang zwischen den Pixel-Werten. Farbton und Sättigung ändern sich in unvorhersagbare Art, und so werden Werte-Zusammenhänge zwischen benachbarten Pixeln entweder so auseinandergezogen oder komprimiert, dass auch Graduierungen unvorhersehbar geändert werden.

Anzeigebezogene Bearbeitung stoppen daher optische Filter (Objektivunschärfe oder -schärfe), Alpha-Blending (das von optischen und geometrischen Definitionen der Okklusion abhängt), Farben und Gradienten (lokale Zusammenhänge zwischen Chrominanz und Luminanz von Pixeln). Sie werden auch mit HDR-Bildern nicht gut skalieren, was zu der Entwicklung von vielen fragwürdigen lokalen und globalen Tonemapping-Methoden führte und dem berüchtigten “HDR-Look” der 2010er Jahre führte.

Heutige Computer sind nicht mehr an Rechenbeschränkungen, wie in den 1990er Jahren, gebunden. Sie können mit unbeschränkten Pixelwerten von 0 bis +unendlich arbeiten, die als reelle Zahlen in Fließkomma-Formaten kodiert werden. Dies ermöglicht, was wir eine “szenenbezogene” Bearbeitung nennen, in welcher Pixel ihre originalen radiometrischen Relationen fast während der gesamten Bildentwicklungs-Pipeline beihalten. In der szenenbezogenen Bearbeitung werden Pixel erst im letzten Teil der Pipeline, in der Anzeigetransformation, für eine Anzeige aufbereitet. Dabei bleiben RGB-Werte der Pixel proportional zur Lichtintensität bei der Kameraaufnahme, was ein genaues Alpha-Blending und optische Filteremulationen ermöglicht, bei gleichzeitiger Skalierung auf einen beliebigen Dynamikumfang im gleichen Algorithmus (SDR, wie auch HDR).

Jedoch haben szenenbezogene Bearbeitungen nicht diese bequemen, festegelegten Werte für Weiß, mittleres Grau und Schwarz, welche die anzeigebezogene Bearbeitungen auszeichnen. Das Setzen dieser Werte anhand der Aufnahmeszene und den Aufnahmebedingungen, liegt jetzt in der Verantwortlichkeit des Nutzers und erfordert eine komplexere Nutzerschnittstelle.

Da szenenbezogene Werte auch als physikalisch aussagekräftig angenommen werden, können Pixel keine Null-Intensität haben. Das würde bedeuten, dass sie überhaupt kein Licht haben, und die Existenz von Null-Licht zerstört viele physikalisch korrekte Algorithmen. tatsächlich bedeuten Weiß und Schwarz nichts bezüglich der Originalaufnahme, die nur eine Ansammlung von Licht in unterschiedlichen Intensitäten ist. Die szenenbezogene Bearbeitung ermöglich einfach, dass beliebig-festgelegte Helligkeitswerte aus der Aufnahme so für ein Ausgabemedium aufbereitet werden, dass sie dort schwarz oder weiß erscheinen.

Versionen vor darktable 2.6 hatten eine nicht-lineare, anzeigebezogene Pipeline mit der Annahme, dass eine nicht-lineare Transformation früh in der Pipeline stattfindet und Mittelgrau wurde ab dann mit 50 % kodiert. Aber nicht alle Module beschnitten Pixel-Werte über 100 %, und sie ließen die Möglichkeit offen, dass diese Werte sich später in der Pipeline wieder erholen würden.

Die Bildtransformation des Moduls Filmic RGB, eingeführt in darktable 2.6, war der erste Schritt in Richtung einer szenenbezogenen Bearbeitung. Damit wurde die notwendige, nicht-lineare Anzeigevorbereitung ans Ende der Berarbeitung verschoben und die Möglichkeit von benutzerdefinierten Schwarz-, Grau- und Weißwerten geschaffen. Das Modul Farbbalance zeigte ferner, wie mit variablen Definitionen von mittlerem Grau gearbeitet werden kann.

Beginnend mit darktable 3.2 konnten Nutzer zwischen zwei Arbeitsabläufen wählen, für die konsistente Voreinstellungen, Module und Modulreihenfolgen für beide anzeigebezogene und szenenbezogene Bearbeitungen bereitgestellt wurden.

In darktable 3.4 wurde ein vollständiges szenenbezogenes Maskieren und Mischen eingeführt, das es erlaubt, Masken für Pixelwerte über 100 % zu definieren und nur unbegrenzte Mischoperatoren zu verwenden.

Umschalten auf szenenbezogen ist ein kognitiver Schritt für die meisten erfahrenen Nutzer, die es gewohnt sind, auf anzeigebezogene Art zu denken. In einem anzeigebezogenen Arbeitsablauf ist es normal, den Weißwert zu verankern und die Tonwerteinstellungen um diesen Punkt drehen zu lassen, um die Helligkeit zu maximieren, aber Beschnitt zu vermeiden. In einem szenenbezogenen Arbeitsablauf sind Schwarz und Weiß fließend und werden auf das Anzeigemedium angepasst. Nutzer sollten das mittlere Grau verankern (das dann so für das Anzeigemedium beibehalten wird) und die Bildtransformation (von Filmic RGB) den Dynamikbereich um diesen Punkt ausweiten oder zusammenziehen lassen. Da ein 10-Bit HDR-Weiß in etwa 4 Mal so hell ist wie ein 8-Bit SDR-Weiß, wird eine feste Zuordnung von Weiß irrelevant. Jedoch ist das Verankern von Mittelgrau sehr komfortabel, da es die durchschnittliche Helligkeit des Bildes unverändert lässt während der Bildtransformation.

Einige Module (Werte, RGB-Stufen_, Farbkurve, RGB-Kurve) sind inhärent inkompatibel mit einer szenenbezogenen Bearbeitung, da ihre grafische Oberfläche implizit RGB-Werte vorgibt, die auf einen Bereich zwischen 0 und 100 % beschränkt sind. Obwohl die Pixel-Operationen, die sie ausfüren, intern unbegrenzt sind und sie daher sowohl in der szenenbezogenen wie auch der anzeigebezogenen Bearbeitung genutzt werden können, erlauben ihre Bedienoberflächen keine Pixel außerhalb des Bereichs von 0 bis 100 % auszuwählen.

Ähnlich ist es mit Überblendungen wie Überlagern, lineares Licht, weiches Licht, hartes Licht, Abdunkeln, Aufhellen, usw., die alle harte Schwellwerte haben und intern eine anzeigebezogene, nicht-lineare Kodierung erwarten.

In darktable 3.4 und höher, zeigt das mit dem Cursor über die Kopfzeile des Moduls fahren zeigt eine Kurzinfo mit Details über die Farbräume, die Bereiche und Kodierungen, die das Modul erwartet. Hier sind die Definitionen der Begriffe, die gebraucht werden:

Linear
Pixel-Werte sind in einer Art proportional zu den radiometrischen Emissionen der Szene, die eine genaue Emulation von physikalischen Filtern erlaubt.
Nicht-linear
Pixel werden so neu skaliert, dass Schatten ein größerer Kodierungsbereich, normalerweise durch einen Austausch der 18.45% Referenz von Mittelgrau ein Wert von zwischen 46 und 50%.
Anzeigebezogene Bearbeitung
Pixel-Werte werden zwischen 0 und 100 % des Anzeigebereichs erwartet, wobei 100 % als der Leuchtwert einer 20 % reflektierenden, weißen Fläche (die weiße Fläche eines Color-Checkers) ist und 0 % die maximale Dichte des Ausgabemediums ist (gesättigte schwarze Tinte oder minimales LED-Panel-Hintergrundlicht).
szenenbezogene Bearbeitung
Pixelwerte werden größer als 0 bis +unendlich angenommen. Die Bedeutung von spezifischen Pixelwerten muss zur Laufzeit durch den Nutzer definiert werden. Szenenbezogene Werte implizieren nicht automatisch eine lineare, radiometrisch-skalierte Kodierung.

translations