Der Szenen-bezogene Workflow

In diesem Artikel werden Sie lernen, was der scenespezifische Workflow ist, wie Ansel ihn nutzt und warum er dem digitalen Bildverarbeitungsprozess wesentlich zugutekommt.

Einführung

Der scenespezifische Workflow bildet das Rückgrat der Ansel-Bildverarbeitungspipeline. Es ist eine Arbeitslogik, die aus der Kinoindustrie stammt, weil sie der einzige Weg ist, um ein robustes und nahtloses Compositing (auch bekannt als Alpha Blending) von überlagerten Grafiken, auf welchem die Filme stark angewiesen sind, um computergenerierte Spezialeffekte nahtlos in das reale Filmmaterial zu integrieren, zu erreichen. Für Fotografen ist es vor allem bei Szenen mit hohem Dynamikumfang (HDR) (Gegenlichtaufnahme, Sonnenuntergänge usw.) nützlich.

Wenn Sie bisher irgendeine Art von Bildverarbeitungssoftware verwendet haben, sollten Sie schon mit einem display-referenzierten Workflow vertraut sein, aber ohne dessen Namen noch seine Grundannahmen zu kennen. Es ist eine Herausforderung zu erklären, wie sich scene-referred von diesem unausgesprochenen display-referred unterscheidet, den Sie gewohnt sind, ohne zu erklären, was display-referred überhaupt war.

Ein Bild machen

Wenn Sie ein Bild einer Szene machen, verwandelt Ihr Kamerasensor ein Lichtspektrum in drei elektrische Signale, ähnlich wie Netzhautzellen dies tun, bevor sie elektrische Impulse an den Sehnerv senden. Die Einzelheiten fallen außerhalb des Rahmens dieses Artikels, aber lassen Sie uns so tun, als ob das Lichtspektrum in drei R, G und B Intensitäten aufgeteilt wird, so dass das Verhältnis von R, G und B in jedem Pixel eine ausreichende Repräsentation der Form des Spektrums ist.

graph TD;
	O[fa:fa-bulb Lichtquelle] --> A;
    A[] --> B["fa:fa-camera Sensor (Nikon D5100)"];
    B --> C[Sensor RGB
];
    A --> D["fa:fa-eye Menschliches Auge"];
    D --> E[Zapfen LMS
];
    E ------> F["fa:fa-brain Menschliches Gehirn"];
    F --> G[Farbreiz
];

    C --> H["fa:fa-laptop Viele digitale Bearbeitungen"];
    H --> HH[sRGB
];
    HH --> I[fa:fa-desktop Bildschirm];
    I --> J[];
    J --> K["fa:fa-eye Menschliches Auge / fa:fa-brain Menschliches Gehirn"];
    K --> L[Farbreiz
];

Wir sollten beachten, dass der Beginn und das Ende der Grafikpipelin ein Lichtspektrum ist, das, wenn identisch, den gleichen Farbreiz für den Beobachter¹ produzieren wird. Aber die Lichtspektren sind tatsächlich ziemlich unterschiedlich: die großen Spitzen des FL1-Lichtes wurden geglättet, sobald sie auf einem sRGB-Bildschirm angezeigt wurden. Der Unterschied zwischen der Originalszene und ihrer Darstellung auf dem Bildschirm stammt von den Signalverlusten, die unvermeidlich sind, wenn ein Spektrum auf RGB reduziert wird, das nur für tageslichtähnliche (glatte) Spektren ausgelegt ist. Diese Annahme wird oft vergessen und das Problem, das wir hier beachten, kommt nicht überraschend, da das FL1-Lämm:

Dieser Leuchtstoff wird rote und violette Oberflächen im Vergleich zu anderen farbigen Oberflächen weniger gesättigt erscheinen lassen und auch ihre Farbtöne verschieben. Blaue und grüne Flächen bleiben weitgehend unbeeinflusst. Allerdings können wir feststellen, dass die tatsächlich wahrgenommene Farbe eines solchen Leuchtstoffs (also der „Weißton“) trotz des spektralen Unterschieds keine sichtbare Verschiebung aufweist. Die relative Farbabweichung ist tatsächlich geringer als 0,001 % in den chromatischen Koordinaten u’v’. Dies alles soll zeigen, dass die Verflechtungen zwischen Spektren (sowohl des Leuchtstoffs als auch des von Materialien, farbigen Oberflächen reflektierten Lichts) und der Farbwahrnehmung weit davon entfernt sind, intuitiv zu sein und eindeutig nicht leicht vorhergesagt werden können.

Ähnlich arbeiten sowohl technologische Organe, die an der Signalaufnahme beteiligt sind, als auch an der Wiedergabe im RGB-Farbmodus. Aber keiner der beteiligten RGB-Räume passt tatsächlich zu den Zapfen LMS. Wenn wir wollen, dass das digitale Bild annähernd der menschlichen Wahrnehmung der Szene entspricht, müssen wir hart daran arbeiten, dies zu erreichen, indem wir das rohe RGB-Signal digital manipulieren, ohne dabei zwangsläufig auf die Wahrnehmung Rücksicht zu nehmen. Es reicht aus, die Konsistenz des Lichtspektrums an beiden Enden sicherzustellen.

Dies ist ein missverstandener Aspekt der digitalen Fotografie, bei dem die digitale Manipulation von Puristen oft als Verfälschung oder Manipulation von Inhalten angesehen wird, und das Rohbild wird oft als eine Art „neutrale“ oder „objektive“ Wahrheit angesehen, weil es von einer Maschine erstellt wurde. Das von der Maschine produzierte Bild ist tatsächlich ziemlich ungenau und die digitale Manipulation ist absolut notwendig, um es trotz aller optischen Verzerrungen, die in der Kamera aufgetreten sind, wie die ursprüngliche Szene aussehen zu lassen.

Die Anpassung des rohen RGB zur Annäherung an das, was der Betrachter in der Szene erlebt hat, erfordert die Manipulation der Farben, unter Verwendung mindestens eines Eingabefarbprofils und einer Weißabgleichsanpassung. Leider sind diese ungenau und stimmen nicht genau mit der menschlichen Sicht überein, insbesondere wenn die Lichtquelle der Szene kein natürliches Tageslicht (mit einem „vollständigen“ Spektrum) ist. Im obigen Beispiel zeigt die Leuchtstofflampe ein stacheliges Spektrum, das einige sehr spezielle Farben gesättigter und heller erscheinen lässt als die anderen, was schwierig zu korrigieren ist.²

Die Eigenschaft dieses rohen RGB-Signals ist, szenenlinear zu sein: Die RGB-Code-Werte sind grob proportional zur Energie der Lichtemission. Dies ist die genaueste Darstellung eines Lichtspektrums, die wir haben können, vorausgesetzt, es gibt eine vollständig spektrale Pipeline (wie in Manuka ).

Leider können wir in den meisten Fällen dieses lineare RGB nicht einfach an den Computerbildschirm senden, selbst nach der Farbanpassung, um sie an die menschliche Sicht anzupassen, gewöhnlich weil:

1. der Dynamikumfang, den Sensoren erfassen können, viel größer ist als das, was Bildschirme darstellen können,
2. um diesen Dynamikumfang besser zu nutzen, unterbelichten Kamerahersteller die Szene um etwa 2/3 EV, wodurch das rohe RGB ziemlich dunkel erscheint.

Daher müssen wir zumindest die Mitteltöne aufhellen und normalerweise die Höhepunkte komprimieren, was die Aufgabe der Darstellungstransformation ist.

In Kamerafirmwares und in typischen Bildbearbeitungsanwendungen wird diese Darstellungstransformation häufig durch eine „Kurve“ erreicht (obwohl die Kurve nur die grafische Darstellung der Transformation ist, nicht die Transformation selbst), die etwa so aussieht:

After

Before

Die Steigung dieser Kurve bestimmt den globalen Kontrast. Viele proprietäre Anwendungen werden eine solche Kurve anwenden, ohne es Ihnen zu sagen, und ohne Ihnen die Möglichkeit zu geben, sie zu deaktivieren, sodass Sie möglicherweise keine Ahnung haben, was im Hintergrund passiert. Einige Anwendungen lassen Sie nur ein Basis-Look zwischen „Standard“, „neutral“, „Porträt“, „intensiv“, „HDR“, usw. wählen, wodurch eine andere Kurve geladen wird. Einige Anwendungen betten die Kurve sogar in das Eingabefarbprofil ein.

Arbeiten an einem Bild

Im vorherigen Abschnitt haben wir gelernt, dass wir nicht nur eine glaubwürdige Farbwiedergabe aus dem rohen RGB rekonstruieren müssen, sondern auch den dynamischen Bereich der Szene für das Zielanzeigegerät richtig neu abbilden müssen. Hier werden wir sehen, wie diese Arbeit tatsächlich ausgeführt wird, indem wir den Schritt „Viel digitale Arbeit“ des vorherigen Abschnitts genauer untersuchen.

Wenn wir verallgemeinern, wie jede Bildverarbeitungssoftware funktioniert, ob typische Desktop-Editoren, Kamerafirmware, mobile Apps, egal welchen Workflow sie verwenden, kommen wir zu diesem Flussdiagramm:

graph TD
    A((fa:fa-sun Szene)) --> B([Raw-Sensor-Ablesung]);
    B --> C;

    subgraph Software;
      C["(Lineare) Farbanpassung"];
      C --> D[Szenenbezogene Verarbeitung];
      D --> E["(Nicht-lineare) Darstellungstransformation"];
      E --> I[Anzeigereferenzierte Verarbeitung];
      I --> G[Farbverwaltungssystem];
    end;

    G --> H([Bildschirm-Puffer]);
    H --> J((fa:fa-lightbulb Anzeige));

    style D fill:#BAFFD2;
    style I fill:#FFB7B5;

Die typischen Bildanwendungen nutzen die szenenbezogene Verarbeitung überhaupt nicht oder nur für einige technische Bildrekonstruktionsfilter, sodass sie direkt von der Farbanpassung zur Darstellungstransformation gehen. Die digitale Manipulation erfolgt ausschließlich im Anzeige-Raum, wo „Weiß“ auf 100 % fixiert wird (oder der Code-Wert 255 bei Verwendung im 8-Bit-RGB), „Schwarz“ wird auf 0 % fixiert (oder der Code-Wert 0 im 8-Bit-RGB), und Mittelgrau ist typischerweise in der Mitte bei 45-50 % (siehe unten mehr Details).

Das Problem dieser Logik liegt im Lebenszyklus des Bildes:

graph LR;
	A[fa:fa-tree Szene] --> B[fa:fa-camera Kamera];
	B --> C[__WORKFLOW__];
	C --> D[fa:fa-poop Farbverwaltungssystem];
	D --> E[fa:fa-desktop SDR-Bildschirm];
	D --> F[fa:fa-sun HDR-Bildschirm];
	D --> G[fa:fa-print Kunstdruck];
	D --> H[fa:fa-book Bücher/Zeitschriften];
	D --> I[fa:fa-tshirt Merch];
	D --> J[fa:fa-save Archive];

Da das Zielanzeigemedium jetzt alles von einem T-Shirt bis zu einem HDR-Bildschirm sein kann und alles dazwischen, müssen wir unterschiedliche Darstellungstransformationen verwenden, um die Eigenschaften des Zielmediums zu berücksichtigen. Aber wenn wir die Darstellungstransformation als den ersten Schritt unserer Bearbeitung verwenden, wird das Ändern sie oft die nachfolgende Bearbeitung ungültig machen, besonders wenn es parametrische Masken verwendet. Das bedeutet praktisch, dass Sie Ihre Bearbeitung für jedes Ausgabemedium erneut durchführen müssen, was mühsam ist.

Das Arbeiten im szenenbezogenen Teil der Pipeline bedeutet, dass wir vor der Darstellungstransformation arbeiten und unsere Bearbeitung immun gegen die Unterschiede im Ausgabemedium wird. Dies ist wie das Arbeiten an einem „Master-Edit“, das gleich bleibt, unabhängig vom Ausgabe, und dann mit den Spezifika der Ausgabe umzugehen, wenn wir den Master exportieren. Das Entfernen des anzeigebezogenen Teils des Workflows ermöglicht es, die Darstellungstransformation und die Farbverwaltungsstufen zu verschmelzen, was sehr wünschenswert ist, da sie alle mit der gleichen Aufgabe zu tun haben: das Mapping des „Master-Edits“ auf das jeweilige Ausgabemedium, indem sie seine Besonderheiten korrigieren, um die beabsichtigte Farberscheinung für das Publikum zu bewahren.

Die Herausforderung beim Arbeiten im szenenbezogenen Teil besteht darin, dass „Weiß“ nicht mehr auf einen bestimmten Wert verankert werden kann, sondern alles Positives bis zur Unendlichkeit sein kann. Um diesem Mangel an Referenz entgegenzuwirken, wechseln wir von einer „weiß-zentrierten“ Pipeline zu einer „grau-zentrierten“ Pipeline, wo das reflektierende Mittelgrau (das der Graukarten) bei 0,18-0,20 verankert erwartet wird. Da das HDR-„Weiß“ bis zu viermal so hell wie das SDR-„Weiß“ sein kann, wissen wir nur, dass alle Geräte ein Mittelgrau um 0,20 haben werden und alle Geräte es anzeigen können, unabhängig von ihrem Dynamikumfang. Es stellt sich auch heraus, dass Bilder natürlicher Szenen die meisten ihrer Histogramme um diesen Wert zentriert haben.

Wir können die Annahmen jedes Workflows unten zusammenfassen:

Die RGB-Codierungen sind die digitale Darstellung des Bildes im Inneren des Computers. Sie sind nicht direkt mit der realen Luminanz verbunden, sei es auf der ursprünglichen Szene aufgenommen oder auf dem Anzeigebildschirm dargestellt. Zum Beispiel wird die Luminanz von schwarzen Pixeln auf physischen Displays bei etwa 0,1 Cd/m² gemessen, während sie im RGB als 0 kodiert wird. Im szenenbezogenen Workflow müssen wir oft das Schwarz so verschieben, dass es nicht-Null-RGB-Werte hat, um wieder mit seiner leuchtenden Bedeutung in Verbindung zu treten, von der wir abhängen.

Wenn man in RGB-Räumen arbeitet, die mit einer OETF  codiert sind (fälschlicherweise als „Gamma“ bezeichnet), wie sRGB, Adobe RGB oder Prophoto RGB, wird das Mittelgrau um 45 % des Kodierungsbereichs erwartet.³ Anwendungen mit einer 8-Bit-Integer-Pipeline müssen OETF-codiertes RGB verwenden, um Posterisation in Gradienten zu vermeiden. Anwendungen mit einer 16-Bit-Integer-Pipeline entscheiden sich oft für das gleiche, obwohl es in diesem Fall keine technische Anforderung darstellt. Mittelgrau wird in displaybezogenen Workflows, die lineares RGB verwenden, das heißt RGB-Räume ohne ihre OETF/Gamma, bei 18 % des Kodierungsbereichs kodiert.

Wir können nun die Annahmen jedes Workflows auf die RGB-Codewerte zu ihrer Bedeutung in Bezug auf reale Luminanz zuordnen:

Die Cd/m²-Werte in der anzeigebezogenen Spalte stammen aus den üblichen Pre-Print-ISO-Standards. Die schwarze Punktluminanz des Displays kann optional im ICC-Profil des Mediums definiert werden, was oft bei professionell erstellten Druckerprofilen der Fall ist, um die Schwarzpunktkompensation  zu ermöglichen. Da das OETF im Inneren des Bildschirms dekodiert wird, ist der Luminanzwert des Mittelgraus mit dem linearen RVB-Codewert verbunden und wird bei 18-20 % der Bildschirmweißluminanz gefunden.

Für den szenenbezogenen Workflow stimmen die Schwarze und Weiße Luminanzen mit den minimalen und maximalen Luminanzen überein, die auf der Szene gefunden wurden. Die Mittelgrau-Referenz ist das Mittelgrau-Feld eines Farbprüfers (oder einer Graukarte), die unter den gleichen Bedingungen wie das Hauptmotiv der Aufnahme beleuchtet wird. Daher ist es möglich, das Mittelgrau direkt durch das Abtasten der Luminanz einer Graukarte in einem Testfoto zu setzen.

Praktische Vorteile des szenenbezogenen Workflows

Wir haben im vorherigen Abschnitt gesehen, dass der szenenbezogene Workflow es Ihnen ermöglicht, Ihren Master-Edit unabhängig von einem festen Zielmedium zu bearbeiten. Die Vorteile davon hören hier nicht auf.

Erstens, weil szenenbezogen um die Idee herum konzipiert ist, dass „Weiß“ keinen besonderen festen Wert hat, kann es sich an jeden Eingabedynamikumfang anpassen, was bedeutet, dass dieselben Werkzeuge und Workflows zur Bearbeitung digitaler Fotos, synthetischen Renderings oder jeder Art von zusammengesetztem HDR verwendet werden können.

Dann, wo es wirklich glänzt, ist für alle optisch definierten digitalen Filter, die reale Effekte nachahmen wollen, wie Weichzeichnen, Entrauschen oder Signale rekonstruieren. Das Beispiel unten zeigt den Unterschied, den es macht, einen digitalen Bokeh-Filter anzuwenden, der eine Linsenblende simuliert, vor oder nach der Darstellungstransformation.

After

Before

Da Linsenunschärfe auf Licht passiert und szenenlineares RGB die nächstgelegene digitale Darstellung ist, die wir von echtem Licht haben können, macht es nur Sinn, optisch definierte digitale Filter im szenenlinearen Teil der Pipeline anzuwenden, aber das obige Beispiel bestätigt visuell die Gültigkeit des Denkens.

Ähnliche Effekte werden beobachtet, wenn mit Masken und Alphakombination gearbeitet wird, wenn man die Kanten der Masken glätten und glätten will, um sie besser mit der Umgebung zu vermischen (was wiederum eine Unschärfe ist).

Wie ist es in Ansel implementiert?

Ansel kann sowohl den anzeigereferierten als auch den szenenreferierten Workflow verwenden, da es einige Altsysteme von darktable erbt. Die meisten anzeigereferierten Module wurden durch szenenreferierte Gegenstücke ersetzt, und die verbleibenden sollten 2023 folgen.

Bald wird Ansel vollständig szenenreferiert sein und dabei intelligentere Darstellungstransformationen in Kombination mit Gamut-Mapping und ICC-Profil-Extraktionen ermöglichen.

Es ist im Allgemeinen nicht möglich, anzeigereferierte Module im szenenreferierten Teil der Pipeline zu verwenden, weil sie einen Weißpunkt bei 100 % erwarten und RGB-Werte über 100 % im Allgemeinen abschneiden (einige müssen dies tun, um numerische Instabilitäten in Algorithmen zu vermeiden). Einige erwarten sogar einen Graupunkt bei 50 %, wie die Alpha Mischmodi  screen, soft light, hard light, overlay, dodge, burn, die Pixel mit Werten, die größer oder kleiner als der 50 %-Schwellenwert sind, unterschiedlich verarbeiten.