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 Arbeitsabläufe, die begrenzte RGB-Wiedergaben und möglicherweise nicht-lineare Transformierungen, um das RGB-Signal zu kodieren, werden “auf Anzeige-bezogen” genannt. Sie basieren auf der Annahme, dass das Bild für Anzeigen in einem frühen Stadium der Bearbeitung bereitet wurden, und sie verankern hart-kodierte Annahmen der RGB werte von Schwarz, Mittelgrau und Weiß. Die meisten der Bildbearbeitung-Algorithmen, die in diesen Arbeitsabläufen gebraucht werden, wurden um diese Annahmen herum abgestimmt. Zum Beispiel die Misch-Modi überlagern erwarten ein Mittelgrau von 50% (oder 128 in 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.
Auf Anzeige-bezogene Pipelines brechen daher optische Filter (Objektiv Unschärfen oder Schärfen) alpha Zusammensetzen (das von optischen und geometrischen Definitionen der Okklusion abhängen), Farben und Gradienten (lokale Zusammenhänge zwischen der Chrominanz und der Luminanz der Pixel). 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 führte.
Moderne Computer sind nicht mehr an dieselben Einschränkungen gebunden, wie in den 1990ern, und können die Pixel-Werte völlig ungebunden (von null bis +unendlich verarbeiten) und als reelle Zahlen kodiert (mit Fließkomma-Formaten): diese Möglichkeiten ermöglichen das, was wir ein auf Aufnahme-bezogenen Arbeitsablauf nennen, in welchem die Pixel deren originalen radiometrischen Zusammenhang, fast während der gesamten Bearbeitungs-Röhre beibehalten. Im auf Aufnahme-bezogenen Arbeitsablauf werden die Pixel erst im letzten Teil der Pipeline für die Anzeige aufbereitet, in der Anzeige werden sie umgewandelt. Das bedeutet, dass die RGB-Werte der Pixel proportional zu der Licht-Intensität der Kamera-Aufnahme bei der Aufnahme beibehalten werden, was ein genaues Alpha-Kompositing und optische Filter-Emulationen ermöglicht, und auch mit dem gleichen Algorithmus zu jedem Dynamikumfang skaliert (SDR wie auch HDR).
Es ist jedoch so, dass auf Aufnahme-bezogene Pipelines die komfortablen fixen Weiß-Werte, die Mittelgrau-Werte und Schwarz-Werte, welche die auf Anzeige-bezogenen Pipelines charakterisieren, und das Setzen dieser Werte, anhand der Szene und den Umständen der Aufnahme, liegt jetzt in der Verantwortlichkeit des Nutzers. Das erfordert eine komplexere Nutzer-Schnittstelle.
Auch, weil auf Aufnahme-bezogene Werte angenommen physikalisch aussagekräftig sind, können Pixel keine 0-Intensität haben. Das würde bedeuten, dass da gar kein Licht war und eine Existenz von Null-Licht viele physikalisch akkuraten Algorithmen zerstört. Als Fakt bedeuten schwarz und weiß nichts in Bezug zur Ursprungs-Szene, die nur eine Ansammlung von Licht in unterschiedlichen Intensitäten ist. Der auf Anzeige-bezogene Arbeitsablauf zielt ganz einfach auf eine Neuzuteilung gewisser willkürlicher Luminanzen, sodass diese in der Anzeige schwarz oder weiß erscheinen.
Versionen vor darktable 2.6 hatten eine nicht-lineare auf Anzeige-bezogene Pipeline, mit der Annahme, dass eine nicht-lineare Transformation früh in der Pipeline stattfinden werde und Mittelgrau wurde dann mit 50% kodiert. Aber nicht alle Module beschnitten Pixel-Werte über 100%, und sie ließen die Möglichkeit offen, dass diese Werte später in der Pipeline sich wieder erholen würden.
Die Bildtransformation des Moduls Filmic RGB, eingeführt in darktable 2.6 war der erste Schritt in Richtung einer auf Aufnahme-bezogenen Pipeline, nicht linear, Anzeige-Vorbereitung am Ende der röhre, mit der Möglichkeit benutzerdefiniert Schwarz-, Weiß- und Grau-Werte zu setzen. Das Modul Farbbalance hat damals einen weg aufgezeigt mit einer variablen Größe von Mittelgrau zurechtzukommen.
Dann in darktable 3.2 konnten die Nutzer zwischen zwei Arbeitsabläufen wählen, die konsistente Standard-Werte definierten, mit Modulen und Pipeline Abfolgen für beide auf Anzeige-bezogene und auf Aufnahme-bezogene Bearbeitungen.
In darktable 3.4 wurde eine voll auf Aufnahme-bezogene Option für Maskieren und Mischen eingeführt, die es erlaubte Masken für Pixel-Werte über 100% zu definieren und nur unbegrenzte Misch-Operatoren zu verwenden.
Umschalten auf auf Aufnahme-bezogen ist ein kognitiver Schritt für die meisten erfahrenen Nutzer, die sich gewohnt sind in auf Anzeige-bezogenen Wegen zu denken. In einem auf Anzeige-bezogenen Arbeitsablauf ist es normal die Weiß-Werte fix zu verankern und die Tonwert-Einstellungen um diesen Punkt drehen zu lassen, zu versuchen die Helligkeit zu minimieren, aber den Beschnitt zu vermeiden. In einem auf Aufnahme-bezogenen Arbeitsablauf sind Schwarz und Weiß fließend und werden an das Anzeige-Medium angepasst. Es wird empfohlen, dass Nutzer Mittelgrau verankern (das dann so beibehalten wird für das Anzeige-Medium) und es lässt die Bildtransformation von (Filmic RGB) den Dynamikbereich um diesen Punkt ausweiten oder komprimieren. Weil ein 10 bit HDR-Weiß ist etwa 4 Mal so hell wie eine 8 bit SDR-Weiß, wird eine fixe Zuordnung von Weiß irrelevant. Jedoch ist das Verankern von Mittelgrau sehr komfortabel, da es die durchschnittliche Helligkeit des Bildes unverändert belässt durch das Sicht-umwandeln.
Gewisse Module (Werte, RGB-Werte_, Tonwert Kurve, RGB Kurve) sind inhärent nicht kompatibel mit einem auf Anzeige-bezogenen Arbeitsablauf, weil deren grafische Schnittstelle implizit
Ähnlich ist es mit Misch-Modi wie Überlagerungen, linearem Licht, weichem Licht, hartem Licht, abdunkeln, etc. die alle harte Schwellenwerte haben, die intern eine auf Anzeige-bezogene nicht lineares Kodieren verlangen.
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%.
- Auf Anzeige-bezogen
- Pixel-Werte werden zwischen 0 und 100% des Wertes des Bereiches der Anzeige, wo 100% als der Leuchtwert einer 20% reflektierenden weißen Fläche (die weiße Fläche eines Color-Checkers) und 0% wird als die maximale Dichte des Ausgabe-Mediums verstanden (gesättigte schwarze Tinte oder ein minimales LED-Panel Hintergrundlicht).
- Auf Aufnahme-bezogen
- Es wird angenommen, dass die Pixel-Werte größer als 0 bis +unendlich sind. Die Bedeutung von spezifischen Pixel-Werten muss durch den Nutzer während der Laufzeit definiert werden. Aus Aufnahme-bezogene Werte implizieren nicht automatisch eine lineare radiometrisch skalierte Kodierung.