Farbregler endlich korrekt

Einführung

Werkzeuge vs. Maschinen, Handwerk vs. Industrie

In seinem Buch The Technological Society  (1954) stellt Jacques Ellul den Unterschied zwischen der vor- und der nachindustriellen Revolution wie folgt dar:

Die vorindustrielle Ära ist die Herrschaft des Werkzeugs und des Handwerks. Die vornehmste Eigenschaft von Werkzeugen ist es, generisch, vielseitig und anpassungsfähig zu sein. Es obliegt dem Handwerker, seine Fähigkeiten zu entwickeln, um die Werkzeuge seiner Absicht folgen zu lassen, sodass die Hand die Grenzen des Instruments ausgleicht. Dieses Konzept ist Musikern noch heute wohlbekannt: Man muss üben, lernen, versuchen, scheitern, erneut versuchen … es gibt keine Abkürzungen. Ellul betont den Gedanken der Sparsamkeit, der mit Werkzeugen einhergeht: Ressourcen sind begrenzt, sodass Ihr Werkzeugbestand im Grunde dadurch bestimmt ist, was Sie sich leisten, tragen, meistern und vor Ort bauen können. Trends ändern sich langsam und sind lokal, weil sie lokale Ressourcen nutzen und sich an lokale Bedürfnisse anpassen, und Werkzeuge folgen demselben Muster. Werkzeuge sind Erbstücke, die vom Meister an den Lehrling, von den Eltern an das Kind weitergegeben werden. Sie werden nicht inkompatibel oder veraltet.

Die industrielle Ära ist die Herrschaft der Maschine. Sie entstammt einer Kultur der Standardisierung und Vermassung. Die Maschine ist weitaus produktiver, weil sie auf eine Aufgabe spezialisiert ist, aber für alles andere ist sie nutzlos und lässt sich nur selten an eine andere Verwendung anpassen. Wenn sich die Produktionsanforderungen ändern, wird die Maschine durch eine andere ersetzt, weil sie zu nichts zu gebrauchen ist. Das ist kein sparsames Schema mehr, und es ist zulässig, weil Ressourcen viel billiger sind und Massenproduktion Skaleneffekte ermöglicht. Dann werden die Menschen zu Dienern der Maschine, und Handwerk wird zum Luxus.

Produktionen, die früher zu Hause oder in kleinen Werkstätten, im familiären Rahmen erfolgten, werden in große Fabriken verlagert, wo genug Platz für Maschinen ist. Das hatte übrigens ganz konkrete Auswirkungen darauf, wie wir unser tägliches Leben organisieren, einschließlich wann und wie oft wir essen¹, sowie auf unsere Schlafmuster². Es ist also nicht übertrieben zu sagen, dass die industrielle Revolution auch die Art und Weise, wie wir denken, was wir für normal oder selbstverständlich halten, tiefgreifend verändert hat.

Das sprach mich an, denn genau so hatte ich seit meinen Anfängen intuitiv Farbbearbeitungswerkzeuge entwickelt: den Versuch, generische Werkzeuge zu bauen, die auf möglichst wenigen Annahmen beruhen, um vielseitig zu bleiben, dabei feinkörnige Kontrolle über die Bildparameter zu geben und letztlich auf die Fähigkeiten der Handwerker zu setzen statt auf halb kaputte, unvalidierte, wie von Zauberhand automatische Werkzeuge, die nur in Idealfällen funktionieren.

Digitale Fotografie: den Prozess automatisieren oder genießen?

Ich habe die Leidenschaft vieler Fotografen, besonders der technikaffinsten, für Ein-Knopf-Workflows und automatisierte Abläufe nie verstanden. Ich habe Klavier gelernt und unterrichtet, und ich bin an das Paradigma shut up and practice gewöhnt: trainieren, um Geläufigkeit zu entwickeln und zu erhalten, und dann dieselben paar Takte immer und immer wieder zu wiederholen, bis der Klang stimmt. An der Qualität, der Textur und der Ausdruckskraft des Klangs zu arbeiten, über das Maß an Gewicht, das man auf die Tasten legt, die Geschwindigkeit des Anschlags, die Bewegung von Handgelenk und Unterarm. Den eigenen Körper für feine Bewegungen einzusetzen und ihn über seine gegenwärtigen Fähigkeiten hinaus zu trainieren, sehr unnatürliche Gesten in Reflexe zu verwandeln. Und schließlich zu lernen, in Gedanken den Klang zu hören, nach dem man greift, noch bevor man die Hände bewegt. All diese Dinge, die sich niemals auf GUI-Schieberegler und Schaltflächen, Metriken, Variablen oder Algorithmen reduzieren lassen.

Die Art und Weise, wie viele Fotografen an die Bildbearbeitung herangehen, klingt, als wären sie durch die digitale Fotografie bestraft worden, weil sie nun eine Software benutzen müssen, um an ihre Fotos zu kommen. Also soll sie auf einen seelenlosen Ablauf reduziert werden, bei dem alles automatisiert werden soll, was sich automatisieren lässt. Wir tauschen Presets und Rezepte aus, manche verkaufen sie sogar. Und jetzt haben wir KI, um den einen oder anderen Stil zu emulieren. Wo ist die Freude daran, künstlerisches Schaffen zu industrialisieren? Was ist der Sinn eines Hobbys, das sich anfühlt wie die Last, seine Fotos entwickeln zu müssen? Kunst ist ein Prozess, keine Prozedur. Welch kranker Geist würde einen Roboter entwerfen, der an Ihrer Stelle töpfert, graviert oder Blumengestecke arrangiert? Wie wäre es, Software als Gelegenheit zu nutzen, um dem Aussehen Ihrer Bilder nach Ihrem Geschmack und Ihrer Sensibilität den letzten Schliff zu geben? Haben wir das pure Vergnügen verloren, die Dinge selbst zu tun, und sei es schlecht? In welchem Alter geht dieser Appetit verloren?

Zugegeben, gegen eine Bildbearbeitungssoftware anzukämpfen, ist eine frustrierende Erfahrung, aber Sie müssen verstehen, wogegen Sie ankämpfen. Ist es bloß die intrinsische Schwierigkeit Ihres Handwerks und Ihr Mangel an Können, oder ist es das schlechte Design des Werkzeugs? Wenn Sie an einem 25-k€-Klavier ringen, das gerade der Klaviertechniker gesehen hat, wissen Sie, dass das Instrument nicht das Problem ist. Aber bei Software, woher wissen Sie es? Nun, Sie können es nicht, bis Sie sich voll und ganz dem Paradigma shut up and practice verschreiben. Gute Retuscheure holen aus jeder Software gute Ergebnisse heraus, der Unterschied liegt darin, wie viel Zeit sie das kosten wird. Und, nun ja, manchmal müssen Sie eine Menge kaschieren wegen der kaputten Farbmodelle von Bearbeitungsanwendungen.

Werkzeuge in der GUI der Bildbearbeitung

In puncto UI-Design ist die Sparsamkeit generischer, vielseitiger Werkzeuge der beste Weg, um nicht von Dutzenden von Funktionen überwältigt zu werden, die einander verdecken, sich in der Funktionalität überschneiden und einfach Ihr Sichtfeld verunreinigen. Es ist Software-Feng-Shui. Aber dann verschiebt sich die Natur der Werkzeuge ein wenig.

Es gibt zwei Denkweisen über die Farbregler der Bildverarbeitung: von ihrem funktionalen Nutzen her und von der Art her, wie sie es erlauben, Farbeigenschaften zu manipulieren. Von ihrem funktionalen Nutzen her:

Man beachte, dass die Farbverschiebung wiederum in zwei Modi aufgeteilt werden könnte: korrigierend (was nach Lichtmodellen verlangt) und kreativ (was nach perzeptuellen Modellen verlangt). So weit werden wir nicht gehen.

Wenn wir dieselbe Liste vom anderen Einstiegspunkt her angehen, von der Art, wie sie es erlauben, Farbeigenschaften zu manipulieren, erhalten wir:

Ich habe nicht die ganze Liste noch einmal gemacht, aber Sie verstehen die Idee: Ob Sie Ihre Werkzeugliste nach Methode oder nach Funktion klassifizieren wollen, Sie enden nicht mit einer 1:1-Zuordnung, außer bei einigen wenigen. Keine dieser Zuordnungen erlaubt es Ihnen also, Ihre Werkzeuge systematisch in einzelne GUI-Elemente zu faktorisieren, um dem Prinzip der Sparsamkeit gerecht zu werden.

Und dann ist die Bildverarbeitung nicht bloß ein Satz von Werkzeugen in einem Kasten, sie ist tatsächlich eine Pipeline von Pixelfiltern, die als Graphknoten in einer Reihenfolge eingefügt werden müssen, die den Eingabeanforderungen der Filter entspricht. Hier ist sie (vereinfacht):

flowchart TD
    r(Raw input) --> d1[Raw denoise]
    d1 --> demosaic[Demosaic]
    demosaic --> d2[RGB denoise]
    d2 --> wb[White balance]
    wb --> bright1["Brightness enhancement (linear)"]
    bright1 --> blur1[Blur / Deblur]
    blur1 --> color_lin["Color shift (linear)"]
    color_lin --> contrast1["Contrast enhancement / Brightness enhancement (non-linear)"]
    contrast1 --> color_nl["Color shift (non-linear) / Colorfulness enhancement"]
    color_nl --> dr[Dynamic range compression]
    dr --> o(Output)

Und, nicht zuletzt, das Problem, das niemand sieht: die Mathematik. Zum Beispiel hat ein geführter Filter, der auf eine Deckkraftmaske angewendet und vom RGB-Bild geführt wird (wie bei der Maskenverfeinerung in Ansel/Darktable), nicht dieselbe Mathematik wie ein geführter Filter, der auf eine Luminanzmaske angewendet und von sich selbst geführt wird (wie beim Tonwert-Equalizer), oder ein volles RGB-Bild, das von sich selbst geführt wird (wie beim Dunstentfernen). Diese müssen mehrfach implementiert werden, mit unterschiedlichen Eingabetypen und unterschiedlichen Arten von Optimierungen. Dasselbe gilt für Methoden, die auf nicht-demosaicten Bildern arbeiten: Wir müssen der Tatsache Rechnung tragen, dass wir an jedem Sensel kein vollständiges RGB-Signal haben, und XTrans-Arrays benötigen eine besondere Mathematik, die sich von Bayer unterscheidet.

Angesichts dessen also:

1. Funktionalitäten haben unterschiedliche Methoden,
2. Methoden lassen sich nicht auf eine einzige Funktionalität reduzieren,
3. alle von ihnen werden als Knoten in eine Pipeline eingefügt, in der die Reihenfolge zählt,
4. Methoden haben Implementierungsvarianten je nach ihrem Eingangssignal, d. h. ihrer Position in der Pipeline,
5. Nutzer wollen Spaß haben, ohne etwas lernen zu müssen,
6. GUI-Überladung nützt niemandem und ermüdet alle,

… wir haben ein Problem: Wie teilt man Funktionen auf und organisiert sie zu einer kohärenten GUI?

In einem professionellen Setup, in dem man von den Nutzern erwarten kann, dass sie selbst eine Pipeline aufbauen können und das Für und Wider ihrer Knoten verstehen, kann man den Weg von DaVinci Resolve gehen und einen nodalen Editor bauen. Dann baut man einen Knoten pro Methode und behandelt die Implementierungsvarianten intern, indem man den Typ des Eingangssignals prüft. Das ist die minimalistischste Art, weil es null GUI-Duplizierung gibt: einfach eine Sammlung von Knoten, und Knoten können parallel gesetzt werden, statt zwangsweise sequenziell. Aber es erfordert Experten als Nutzer.

Der Weg von Lightroom/Capture One besteht darin, vollständig zu verbergen, dass es überhaupt eine Pipeline gibt, und eine flache GUI bereitzustellen. Dann erfolgt die Mehrfachinstanziierung von Knoten über Masken: Das Hinzufügen neuer Masken erlaubt es Ihnen, ihnen eine Teilmenge der Software-Regler zuzuweisen, um die maskierten Regionen selektiv zu bearbeiten. Doch das geht auch damit einher, dass keine dieser Anwendungen szenenbezogene lineare Bearbeitung erlaubt, was das Weichzeichnen, Schärfen, Entrauschen und die eigentlichen Maskenübergänge fehlerhaft macht.

Ansel geht einen Mittelweg. Erstens gibt es jetzt einen Prototyp eines nodalen Editors:

Dies erlaubt es uns, die Reihenfolge der Pipeline explizit anzuzeigen, sie manuell umzuordnen und die Reihenfolge-Presets zu ändern, auf eine Weise, die auch Ein- und Ausgänge zeigt. Zuvor hatten wir nur den Stapel von GUI-Modulen in der rechten Seitenleiste, der die Pipeline-Reihenfolge gewissermaßen andeutete, wenn man ihn als Ebenenstapel las, aber er wurde von den Nutzern oft als bloße Bequemlichkeit zur Umordnung des GUI-Werkzeugkastens missbraucht.

Und dann ist die Funktionsaufteilung hybrid:

• Die Module Kontrast-Equalizer, lokaler Kontrast und diffundieren oder schärfen sind ihrer Natur nach intrinsisch dual: Sie können den lokalen Kontrast und die Schärfe je nach ihren Parametern erhöhen oder verringern. Der Kontrast-Equalizer hat sogar eine Entrauschmethode, was Sinn ergibt, weil das Schärfen das Rauschen erhöht, sodass der richtige Ort, um es unter Kontrolle zu halten, dort ist, wo es entsteht. Das sind methode-zuerst-Module.
• Der Weißabgleich dupliziert die Funktionalität des Teils der chromatischen Adaptation aus der Farbkalibrierung. Der Weißabgleich ist eine einfache kanalweise Normalisierung, die in Sensor-RGB stattfindet und von einigen Entrasterung-Methoden benötigt wird (besonders für XTrans-Sensoren), während die Farbkalibrierung eine viel perzeptuell genauere Illuminanten-Kompensation im CIE-CAT16-Raum durchführt. Dieser Raum ist vom CIE-XYZ-1931-Raum aus definiert, den wir erst nach der Eingangs-Farbprofilierung erhalten (und die erfordert ein demosaictes Bild, um zu funktionieren). Es gibt unterschiedliche Gründe und Bedürfnisse für beide, und sie müssen an unterschiedlichen Stellen in der Pipeline sitzen. Das sind pipeline-zuerst-Module: Obwohl sie funktional ähnlich erscheinen, machen ihre Existenzgründe und ihre internen Anforderungen (und völlig unterschiedliche Mathematik) sie viel verschiedener, als Sie vielleicht denken. Dasselbe gilt für die verschiedenen Entrausch-Module: Einige arbeiten auf RAW-Eingaben, andere nicht, und einige arbeiten besser auf nichtlinearen Signalen.
• Die Farbbalance wurde als Alles-in-einem-Farbmodul konzipiert, das eine erweiterte ASC CDL  (Slope-Offset-Power) anwendet und dann globale und luminanzweise Sättigung und Chroma handhabt und damit frühere Darktable-Module wie Kontrast-Helligkeit-Sättigung, Dynamik und Velvia ersetzt (alle im CIE Lab 1976 arbeitend). Für sich allein genommen ist es ein funktionalität-zuerst-Modul, aber es ist nicht das einzige farbverschiebende Modul. Die anderen farbverschiebenden Module verwenden sehr unterschiedliche Methoden (Matrizen, LUTs oder farbtonweise Regler), die 3- bis 9-mal weniger rechenaufwendig auszuführen sind und in unterschiedlichen Farbräumen arbeiten.

Ansel erbt sein Konzept der Module von Darktable: Module sind zugleich ein GUI-Werkzeugkasten-Widget und ein irgendwo in der Pipeline eingefügter Pixelfilter. Sehr kleine Module zu entwerfen (funktional gesehen) wird also viele hochrangige GUI-Widgets in der rechten Seitenleiste hervorbringen, während der Entwurf sehr großer Module weniger hochrangige Widgets ergibt, die aber höher sind oder mehr interne Tabs verwenden. Die zweite Option könnte dennoch vorzuziehen sein, weil hochrangige GUI-Module wie Ablagen wirken, sodass weniger Ablagen, die funktional konsistent sind, dabei helfen, die hochrangige Funktionsaufteilung besser zu verstehen (wie ein Inhaltsverzeichnis).

Aber dabei bleibt es nicht, denn wieder … Knoten. Ein Modul sollte ein Satz von Farbreglern sein, die als mehrfach instanziierter, maskierter Knoten in der Pipeline konsistent sind. Es ist nicht gut, ein Modul mit Dutzenden von Funktionen vollzustopfen, von denen die Hälfte als globale Einstellungen sinnvoll ist und der Rest nur in der Lokalität der Maske; sie werden, einmal instanziiert, nur CPU-Zyklen für nichts verbrauchen.

Und schließlich gibt es die Performance. Farbregler, die in einem bestimmten Farbraum arbeiten müssen, benötigen eine Farbumwandlung hin und zurück, die CPU-Zyklen verbraucht, sodass es besser ist, wenn sie alle im selben Modul laufen, sofern sie funktional zusammen Sinn ergeben. Außerdem wird jedes neue Modul eine neue Schleife über die Pixel ausführen, was bedeutet, dass es das Bild ein weiteres Mal aus dem/in den RAM in den CPU-Speichercache verschiebt. Das Zusammenfassen von Funktionen in dieselbe Schleife verhindert also zusätzlichen Missbrauch der I/O-Bandbreite und hilft der Performance.

Wenn wir also die ganze Liste der Randbedingungen rekapitulieren, ist dies eine wirklich schwierige Herausforderung, die es zu lösen gilt:

1. wir sollten stets danach streben, die wenigsten GUI-Elemente zu bauen, weil eine überladene GUI alles schwer auffindbar (und kognitiv überwältigend) macht: Der beste Ort, um einen Baum zu verstecken, ist im Wald,
2. die Überladung, die wir bauen, sollte von global zu lokal, generisch zu spezifisch, häufig genutzt zu Nische organisiert sein, weil das die einfachste Art ist, darüber nachzudenken: Sich die GUI-Struktur als „Inhaltsverzeichnis" vorzustellen, ist das Beste, was mir bisher eingefallen ist,
3. aber es zur Regel zu machen, Funktionen systematisch auf Grundlage der Funktionalität oder auf Grundlage der Methode aufzuteilen, endet dennoch in beiden Fällen mit Duplizierungen, es sei denn, wir gehen in die Richtung des vollständigen Knoten-Editors, machen alles methodenbasiert und übertragen die Verantwortung, Pipelines zu bauen, auf den Experten-Nutzer,
4. Module sollten wann immer möglich als funktionalität-zuerst entworfen werden, aber eine Menge Einschränkungen greift:
   1. der Typ des Eingangssignals, der die Position in der Pipeline bestimmt und uns zwingen kann, pipeline-zuerst zu priorisieren und Werkzeuge zu duplizieren,
   2. die Relevanz und Konsistenz des Satzes von Modulreglern, wenn er mehrfach instanziiert und maskiert wird: Ein Modul sollte eine konsistente Einheit des Bearbeitungs-Workflows sein, kein Sammelsurium, in das man alles hineinquetscht. Insbesondere: Wenn es (workflow-technisch) Sinn ergibt, eine Maske nur auf eine Teilmenge der Modulfunktionen anzuwenden, dann sollte diese Teilmenge ihr eigenes Modul sein,
   3. Performance-Probleme (Farbraum-Hin-und-Rück, Gamut-Mapping der Ausgabe, I/O-Bandbreite): Wir können nicht an die Ergonomie für den Nutzer allein von der UI-Seite her denken; die Laufzeitgeschwindigkeit ist ebenfalls Teil der Ergonomie,
   4. die mathematische Natur der ausgeführten Operationen: Einige Methoden (besonders Schärfen/lokaler Kontrast) können je nach Vorzeichen ihrer Parameter entgegengesetzte Effekte haben, einige Methoden eignen sich schlecht dafür, im selben Pixelfilter zusammengefasst zu werden,
5. schließlich muss die Anzahl der Klicks/Scroll-Schritte, die nötig sind, um eine häufig genutzte Funktion zu erreichen, berücksichtigt werden, weil die Achse generisch -> spezifisch nicht immer parallel zur Achse häufig genutzt -> Nische verläuft. Während also die hochrangige Organisation generisch -> spezifisch kognitiv Sinn ergibt, ist sie nicht immer die ergonomischste.

All diese gegensätzlichen Anforderungen müssen von Fall zu Fall abgewogen werden, indem man die Gesamtheit der Pipeline betrachtet, sonst bauen wir keine Workflow-Anwendung, sondern eine Plugin-Registrierung. Sie liegen an der Kreuzung zwischen hardwarenaher Programmierung, Mathematik, Retusche-Workflow und UI-Ergonomie, und keines dieser Konzepte ist im Allgemeinen wichtiger als die anderen. Manche dieser Randbedingungen sind jedoch leichter zu verstehen als andere, wodurch sie sehr viel mehr Aufmerksamkeit erhalten, in einem typischen Streetlight-Effekt : Probleme immer weiter in der Schicht zu jagen, die man versteht, während man ihren wahren Ursprung völlig verwirft, weil er eine Schicht berührt, die man nicht versteht/von der man nichts weiß. Deshalb ist es eine echte Zumutung, mit „UX-Designern" zu arbeiten, weil ihnen typischerweise der Hintergrund fehlt, um über die GUI hinauszublicken, und es ihnen oft egal ist, dass es unter der UI eine Engine zu steuern gibt. Man kann nicht einfach beschließen, die Schwerkraft aufzuheben, weil man den Nick -Regler für eine einfachere UI entfernen möchte.

Design ist ein Prozess iterativer Verfeinerungen unter Nutzer-Feedback. Manche dieser Iterationen werden von Makro zu Mikro neu gestalten (globale Anwendungsarchitektur bis zu den inneren Reglern des Moduls), und manche werden von Mikro zu Makro neu gestalten, bis es zu einer einheitlichen Semantik und einer kohärenten Funktionsaufteilung konvergiert. Es ist töricht zu glauben, dass irgendjemand es in einem Durchgang richtig hinbekommt, oder zu glauben, dass nur eine der Mikro-/Makro-Ebenen behoben werden müsste. Es ist eine Brücke, die man von beiden Enden gleichzeitig baut, und man muss einen Weg finden, sie in der Mitte zusammentreffen zu lassen.

Die Eigenschaften guter Farbregler

Aus meinen 17 Jahren Erfahrung beim Bearbeiten von Bildern und 8 Jahren Erfahrung im Studium und Experimentieren mit Bildverarbeitungsmathematik gibt es ein paar Dinge, die ich darüber gelernt habe, was ein guter oder ein schlechter Farbregler ist. Mit „Farbregler" meine ich irgendeine Art, eine Nutzerabsicht an einen Pixelalgorithmus zu übergeben, der eine visuelle Eigenschaft eines Bildes bearbeitet. Gute Farbregler:

1. sind orthogonal zueinander, das heißt, ein Regler ändert zu einem gegebenen Zeitpunkt eine Farbdimension und zwingt Sie nicht, an einem anderen Regler auszugleichen,
2. sind aus perzeptueller Sicht gleichmäßig skaliert, das heißt, von „0" auf „1" zu gehen wird das visuelle Ergebnis um denselben Betrag ändern wie von „1" auf „2" zu gehen. Das ist leider nicht immer möglich, weil Mathematik und Physik Sie hassen.
3. skalieren anmutig mit zunehmendem Dynamikumfang, was so ziemlich alle Farberscheinungsmodelle ausschließt (CIE Lab 1976, CIECAM 16, dt UCS 22), die für SDR auf Datensätzen von gemalten Farbfeldern erstellt wurden.
4. degradieren anmutig, wenn wir die Stärke der Änderungen erhöhen, das heißt, sie können übertrieben werden, aber können nicht den Bildinhalt ändern und Artefakte erzeugen,
5. bewahren Bildgradienten, das heißt, sie behalten die tonalen und chromatischen lokalen Variationen als Variationen bei, statt sie zu verflachen, überschwingen zu lassen (Halos, Farbsäume, Rauschen usw. zu erzeugen) oder umzukehren.
6. erlauben es Künstlern, ihrer Absicht in der kürzesten Zeit so nahe wie möglich zu kommen.
7. sind nicht dupliziert.

Aus 1. leiten wir zum Beispiel ab, dass jede Art von RGB-Tonwertkurve schlecht ist, weil sie die Lichter entsättigt und die Schatten sättigt, als Nebenprodukt des Maßes an (Luminanz-)Kontrast, das Sie hinzugefügt haben, und Sie können das Maß der Sättigungsänderung, die Sie für das Maß der angeforderten Kontraständerung erhalten, nicht kontrollieren (oder dekorrelieren), außer durch Tricks wie die Bewahrung von RGB-Verhältnissen oder das manuelle Zurechtkneten der Sättigung/Entsättigung über die Anwendung der Tonwertkurve. Das ist der Existenzgrund für den Tonwert-Equalizer, der den Kontrast korrigiert, indem er eine selektive Belichtungsanpassung statt einer Tonwertkurve verwendet.

Aus 2. leiten wir ab, dass GUI-Regler wann immer möglich Farberscheinungsmodelle verwenden sollten.

Aus 3. leiten wir ab, dass die in der GUI verwendeten Farberscheinungsmodelle nicht auf Pixeln verwendet werden sollten, sondern umgewandelt werden sollten, sodass Pixel in RGB behandelt werden. Das ist ein typisches Model-View-Controller -Paradigma, das in allen Bildverarbeitungsanwendungen konsequent ignoriert wird. Anscheinend gibt es unter Entwicklern den Glauben, dass das Farbmodell der Pixel 1:1 dem Farbraum des GUI-Controllers entsprechen sollte.

Aus 4. leiten wir ab, dass Regler, die praktisch nur auf einer kleinen Teilmenge ihres Wertebereichs nutzbar sind, schlechte Mathematik, schlechte Farbmodelle, schlechte Priors verwenden. Die Fehlermodi sind genauso wichtig wie das, was passiert, wenn man die Regler in ihrem optimalen Bereich verwendet.

Aus 5. bestätigen wir bloß den Punkt 3.

Aus 6. haben wir ein neues Problem aufgeworfen: Viele Fotografen haben keine Retusche-/Bearbeitungsabsicht (im Sinne von: ein visuelles Endziel), sondern schieben und ziehen nur Schieberegler in die Richtung, die das Bild schöner erscheinen lässt, und enden mit einem glücklichen Zufall, den sie nicht reproduzieren könnten (oder verwerfen das Bild, weil sie es nicht bearbeiten können). In diesem Fall gibt es keine Erfolgsmetrik für die Regler, weil es keine Differenz zu berechnen gibt zwischen Absicht und Ergebnis, da die Absicht undefiniert ist. Deshalb müssen wir, wenn wir mit Nutzer-Feedback arbeiten, kritisch sein und untersuchen, wer spricht und von wo aus. Das heißt: Nicht jedes Nutzer-Feedback ist gutes Nutzer-Feedback (und jahrelange Erfahrung ist für sich genommen kein Beweis für irgendetwas).

Und 7. ist bloß eine Erinnerung an den vorherigen Abschnitt: Eine Einstellung duplizieren zu müssen ist gewöhnlich ein Indiz für schlechte Funktionsaufteilung, oder Sie müssen einen guten Grund dafür haben.

All das sind offensichtlich die Idealfälle, denen man zustreben sollte. In der Praxis müssen Sie verschiedene Kandidaten bewerten und den besten auswählen, der selten alle Anforderungen erfüllen wird. Aber um konkurrierende Kandidaten zu bewerten, brauchen Sie zunächst objektive Prüfpunkte und Skalen. Das sind die Prüfpunkte, die mir über die Jahre offensichtlich geworden sind.

Die Eigenschaften guter Bearbeitungs-Workflows

Ich erinnere mich an endlose E-Mail-Ketten vor 9 Jahren auf der Darktable-Mailingliste (mittlerweile eingestellt), darüber, wie man die GUI am besten neu organisiert, in denen mir gesagt wurde: „Es gibt keinen richtigen oder falschen Workflow, nur persönliche Vorlieben." Absoluter Relativismus ist immer dümmer, als er klingt. Diese Dummheit setzt sich nun auf discuss.pixls.us fort. Es sind wirklich dieselben Diskussionen, die dasselbe über dieselben Probleme sagen, sich seit über 9 Jahren im Kreis drehen, und immer noch keine greifbare Lösung, welche auch immer.

Zunächst gibt es den offensichtlichen Fall, in dem Sie eine parametrische Maske definieren, sagen wir auf Farbbalance RGB, und sie so einstellen, dass RGB-Werte zwischen irgendwas und irgendwas + Epsilon einmaskiert werden. Dann sind Sie mit den Farben zufrieden, aber Ihr Bild sieht ein bisschen dunkel aus, also erhöhen Sie die Belichtung. Nun ist Ihre parametrische Maske ungültig, und Sie müssen sie erneut machen, weil Belichtung in der Pipeline früher sitzt als Farbbalance RGB, sodass Sie Ihren gesamten Bereich von RGB-Codewerten verschoben haben. Das ist zirkuläres Bearbeiten, es ist der am besten vermeidbare Zeitverlust, und wenn Sie ihn verhindern wollen, gibt es nicht viel Wahl: Sie müssen auf Ihre Pipeline-Reihenfolge achten. Zirkuläres Bearbeiten ist ein objektiv schlechter Workflow. Muss ich das begründen?

Es hört nicht bei den Masken auf, denn viele Farbmodule müssen das HDR-Weiß normalisieren, um Farbmodelle verwenden zu können, die nur unter der Annahme arbeiten können, dass Weiß = {1, 1, 1}. Deshalb setze ich diese später in die Pipeline, nach den globalen Anpassungen von Helligkeit und Kontrast.

Und dann gibt es den Fall der Stapelbearbeitung: Sie haben eine Serie von Bildern zu bearbeiten, Sie wollen, dass sie über die ganze Serie hinweg konsistent aussehen, aber sie haben geringfügige Variationen in Beleuchtung, Kontrast und Farbtemperatur. Der einzige Weg, das zum Funktionieren zu bringen, ist ein erster Schritt der Bildnormalisierung, um individuelle Bildvariationen zu handhaben und sie in einen konstanten Zustand zu überführen. Sobald das geschehen ist, können Sie denselben Stil per Stapel anwenden oder die Historie der späteren Module oben drauf kopieren, weil dieser nächste Schritt normalisierte „konstante" Eingaben erhält und daher konsistente (wenn nicht gar konstante) Ausgaben produzieren sollte. Diesen ersten Schritt der Normalisierung nicht zu erreichen, wird den nächsten völlig unzuverlässig und unvorhersehbar machen, was den Zweck der Stapelbearbeitung zunichtemacht. Und selbst mit diesem scheinbar starren Workflow werden Sie dennoch am Ende individuelle Feinabstimmungen vornehmen müssen, wenn Sie wirklich konsistente Ergebnisse wollen. Das ist nicht meine Meinung, es ist eine einfache Tatsache: Wenn Sie konsistente Ausgaben für einen Satz von Bildmodifikationen mit starren Einstellungen wollen, brauchen Sie konsistente Eingaben.

Aber das hat eine Grenze, denn wenn Sie an einem HDR-Signal arbeiten, müssen Sie Ihr HDR-nach-SDR-Tonemapping früh einrichten, damit Sie tatsächlich sehen können, was Sie in Ihrem Bild tun, ohne dass die Lichter beschnitten werden. Es gibt also einen ersten Schritt, in dem man sich einen Überblick über seinen Inhalt verschafft, und dann einen Schritt, in dem man die Grenzen des Dynamikumfangs finalisiert. Das bedeutet, dass Sie immer zuerst die globale Belichtung einrichten sollten, indem Sie auf die Mitteltöne schauen (und auf nichts anderes), und dann Ihren vorläufigen Arbeits-Tonemapper einrichten sollten. Diese Regel, den Workflow 1:1 an der Pipeline-Reihenfolge zu verankern (die ihrerseits an den Eingabeanforderungen der Module verankert ist), hat also einige Ausnahmen und kann nicht ohne Unterscheidungsvermögen angewendet werden.

Was bedeutet, dass Sie all das gelernt haben sollten. Gute Workflows stammen von Menschen, die darüber nachgedacht haben, wie sie sich an die Werkzeuge anpassen, die sie verwendeten, indem sie diese sowohl vom praktischen als auch vom theoretischen Aussichtspunkt aus betrachteten, und nicht von den fröhlichen Camplern, die all die Gewohnheiten, die sie über die Jahre angenommen haben, fälschlicherweise für einen Workflow hielten. Nochmals, es passieren Dinge unter der GUI-Oberfläche, wir schreiben keine Briefe in einer Textverarbeitungs-App. Seit über 9 Jahren brülle ich in Endlosschleifen in Foren: ES IST EINE PIPELINE, KEIN ZUSAMMENHANGLOSER SATZ VON ZUFÄLLIGEN BILDREGLERN. Die Reihenfolge zählt. Wenn es nur eine Sache gibt, die Sie in diesem ganzen Gebrabbel verstehen, dann sollte es diese sein.

Und ich denke, Lightroom hat den Erwartungen und dem Verständnis der Nutzer viel Schaden zugefügt, indem es seine interne Pipeline verbirgt. Aber es funktioniert für Lightroom, weil es den Nutzern viele Freiheitsgrade nimmt. Darktable hat viel von Lightrooms UI-Semantik wiederverwendet und dabei schrittweise mehr Freiheit und direkte Kontrolle über die Pipeline-Knoten angeboten (über die Jahre wurden das modulweise Maskieren eingeführt, dann die Mehrfachinstanziierung von Modulen und das Umordnen relativer Instanzen, dann Rastermasken, die zwischen nicht aufeinanderfolgenden Modulen wiederverwendbar sind, und schließlich das vollständige Umordnen von Modulen), was Alteingesessene und Neulinge gleichermaßen verwirrt hat.

Die Idee einer Pipeline ist nicht einmal spezifisch für die digitale Fotografie. Auch die Ölmalerei hat gewissermaßen eine Pipeline, bei der man zunächst seinen Malgrund vorbereitet, ihn mit Grundierung überzieht, um ihn weniger saugfähig zu machen, dann die Umrisse setzt, dann den Hintergrund vorbereitet, dann seine Lasur  schichtet und schließlich die Firnisschicht aufträgt. Niemand, der bei klarem Verstand ist, würde mit dem Firnis beginnen und mit der Grundierung enden. Die analoge Fotografie hat offensichtlich eine Pipeline aus chemischen Bädern, Zeitschaltuhren und dergleichen. Und Malprogramme wie Photoshop, Gimp oder Krita haben eine explizite Pipeline, die durch Ebenen materialisiert wird, welche einander verdecken, von unten nach oben, mit Effektebenen, die nichts anderes sind als parametrische Pixelfilter, die dynamische Ausgaben produzieren.

Aber irgendwie, weil RAW-Bildbearbeitungssoftware es von den materiellen Realitäten losgelöst erscheinen lässt, scheint es im Digitalen in Ordnung zu sein, ohne Struktur oder Methode zu arbeiten. Der „nichtdestruktive" Bearbeitungs-Workflow könnte hier auch großzügig als YOLO  ausgelegt worden sein, was ebenfalls nicht hilft. Nur weil Sie Ctrl+Z haben, heißt das nicht, dass plötzlich alles verzeihlich ist.

Zusammengefasst: Gute Bearbeitungs-Workflows sind diejenigen, die Ihnen bei jedem Schritt vorhersehbare Ergebnisse liefern und dabei zirkuläres Bearbeiten vermeiden. Sie müssen von der Pipeline-Reihenfolge geleitet werden, aber sie können nicht die ganze Zeit 1:1 an ihr kleben, und Sie müssen Ihr Urteilsvermögen einsetzen, um zu unterscheiden, wann Sie bei der Pipeline bleiben und wann Sie abweichen. Das lässt sehr wenig Raum für persönliche Vorlieben.

Die Ethik der digitalen Bildverarbeitung

In analogen Zeiten arbeiteten Künstler mit physischen Medien und konnten alle möglichen Tricks anwenden und neue Techniken finden, um maßgeschneiderte Ergebnisse zu erzielen. Es war zugänglich, weil man das Medium, mit dem man arbeitete, physisch berühren konnte. Künstler waren frei.

Digitale Kunst ist von Natur aus gewaltsam, insofern sie den Künstlern die Freiheit genommen hat: Jetzt können sie nicht selbst neue Techniken finden, weil ihre Kunst als reine Information in irgendeinem Computerspeicher existiert, sodass sie auf das beschränkt sind, was die Anwendungen anbieten, und entweder Software-Herausgeber/-Entwickler anflehen können, ihre Bedürfnisse zu berücksichtigen, oder lernen können zu programmieren und sie selbst zu programmieren (was eine ziemliche Eintrittsgebühr ist, wenn man keinen technischen Hintergrund in angewandten Wissenschaften oder Informatik hat). Der Verlust der Freiheit kann durch die Tatsache verdeckt werden, dass alles, was in Software gemacht wird, umkehrbar ist, sodass Fotografen zum Beispiel Negative nicht dauerhaft beschädigen. Schlimmer noch, Software kann Sie produktiver machen, sodass es aus geschäftlicher Sicht ein Nettogewinn ist. Aber das sollte nicht die Tatsache verbergen, dass Künstler in eine passivere Konsumentenposition als zuvor gebracht werden, beherrscht von denen, die wissen, wie man für sie programmiert, und es tun wollen, und die entscheiden dürfen, wie sie von nun an Kunst machen.

„Gewalt", „Unterdrückung der Freiheit", „Beherrschung" … Sie wissen, worauf das hinausläuft: Es nennt sich Unterdrückung. Eine sexy Unterdrückung, die Ihnen verspricht, professionelle Ergebnisse in nur wenigen Klicks zu erzielen, ohne eine Fotoschule besuchen zu müssen. Oder, im Kontext freier Software, eine Unterdrückung, die wohlwollend und harmlos erscheint, weil nichts zu bezahlen ist und Datenschutz eingebaut ist. Aber nichts davon ist unvereinbar mit der Tatsache, dass wir, die Entwickler kontrollieren, was Sie in/an Ihren Bildern tun dürfen oder nicht, weil wir den Code kontrollieren. Nicht weil wir von den Nutzern gewählt wurden, nicht weil wir für die anstehende Aufgabe kompetent sind (inzwischen habe ich hier viele Male demonstriert, dass das Darktable-„Team" nichts als ein Haufen ahnungsloser Idioten mit zu viel Freizeit war), einfach weil wir Admin-Rechte auf irgendeinem GitHub-Repository haben. Das gibt uns Macht, und Macht kommt mit Verantwortlichkeit.

Das beschäftigt mich nun schon seit mehreren Jahren im Hinterkopf, weil es auch zu einem ethischen Dilemma wird (zusätzlich zu all den zuvor erwähnten technischen), zu entscheiden, welche Funktionen hinzuzufügen, zu entfernen oder umzustrukturieren sind. Zugleich ist es nicht möglich, es jedem recht zu machen, und es würde am Ende jeden mit vielen Nischenwerkzeugen überwältigen, die sie nie nutzen werden (nochmals: einen Baum im Wald verstecken). Dann ist es auch mehr Code zu warten, also mehr Arbeit und eine Last für die Maintainer in der Zukunft, mit mehr Bedrohungen für die Stabilität der Software. Ein Schweizer Taschenmesser zu bauen, das ständig halb kaputt ist, wird niemandem helfen.

Es bleibt aber dabei, dass das Entfernen von Reglern zugunsten der Vereinfachung der GUI möglicherweise gerade das Entfernen von Freiheit ist, wenn wir nicht sicher sind, dass ähnliche Funktionalität auf die eine oder andere Weise in der Software weiterhin existiert. Künstlerische Freiheit ist keine Handelsware, sie ist ein notwendiger Hauch frischer Luft in Gesellschaften, die zunehmend in den (Techno-)Faschismus abdriften, wieder einmal.

Nochmals, all das muss von Fall zu Fall abgewogen werden. Bildverarbeitungs-Apps in alle Richtungen zugleich laufen zu lassen und zu versuchen, alle Bedürfnisse in einer einzigen App zu bedienen, selbst die eigenartigsten, wird fünfbeinige Schafe bauen, die für niemanden praktisch zu benutzen sind. Was zu meinem ersten Abschnitt zurückführt: generische, vielseitige und annahmefreie Werkzeuge zu bauen, die sich auf faktorisierte Weise an viele verschiedene Bedürfnisse anpassen lassen. Industrie vs. Handwerk.

Produktivität wird durch Spezialisierung erreicht (die, kombiniert mit Standardisierung, Automatisierung ermöglicht), Spezialisierung wird durch Duplizierung erreicht, Duplizierung erzeugt GUI-Aufblähung und -Überladung, Aufblähung und Überladung sind die Feinde von UX und Kreativität. Die Schlussfolgerung aus all dem ist: Lasst uns wählen, was es wert ist, spezialisiert zu werden, und behindern damit die Freiheit der Nutzer. Daher ist Produktivität das falsche Paradigma: Ihre natürliche Schlussfolgerung ist Unterdrückung.

Das Gegenteil von Produktivität ist Robustheit und Vielseitigkeit. Es mag langsamer sein (ist es das aber?), aber wir können eine größere Vielfalt von Fällen mit derselben Anzahl von Werkzeugen bewältigen, ohne willkürlich Optionen zu entfernen und damit die Freiheit der Nutzer. Das Konzept der Robustheit wurde bereits im Kontext sozialer und klimatischer Instabilität von Olivier Hamant in seinem Buch Antidote to the cult of performance. Robustness from nature  (2024) entwickelt. Eine seiner Hauptaussagen ist, dass der Kult der Leistung (oder Effizienz) nur zu Wettbewerb führt, der Gewalt fördert, und in den unstabilen kommenden Zeiten brauchen wir Kooperation. In einer Gesellschaft, die mehr als genug produziert, um jedermanns Bedürfnisse zu decken (es aber schlecht verteilt), gewinnt uns Leistung nichts außer mehr Profiten (nochmals, schlecht verteilt). Aber was sie sicher produziert, ist Burn-out, sowohl in Menschen als auch in Ökosystemen.

In Software kann Burn-out von mehreren Dingen herrühren:

1. Technostress , verbunden mit zu vielen Anwendungen, Werkzeugen, Standards und Paradigmen, an die man sich anpassen muss,
2. Informationsüberflutung , verbunden mit einem Überangebot an GUI-Widgets und Werkzeugen, durch die man navigieren muss,
3. Veränderungsmüdigkeit , verbunden mit zu häufigen Updates, die Workflows verändern.

Zusammenfassend: Das Hinterherjagen von Leistung kaskadiert in eine Reihe von Nachteilen:

1. aus technischer Sicht bedeutet es, mehr spezialisierte Werkzeuge bauen zu müssen, die die GUI überladen, was Informationsüberflutung erzeugt,
2. aus UX-Sicht impliziert das Halten von Überladung und Überflutung in vernünftigen Grenzen, willkürlich zu wählen, wessen Bedürfnisse gedeckt werden (wahrscheinlich die der Mehrheit) und wessen Bedürfnisse ignoriert werden, was jedem, der zu stark vom Mainstream abweicht, die künstlerische Freiheit nimmt: Das ist eine Premiere in der Kunstgeschichte, und keine noch so große Software-Freiheit macht es weniger gewaltsam,
3. aus Marketing-Sicht brauchen nur Profis Produktivität, und im Moment scheinen sie in großer Mehrheit kommerzielle Software zu bevorzugen. Es gibt keinen Nutzen für Open Source, „neue Märkte zu erobern", sie sollte vielmehr danach streben, die zurückgelassenen Nischen abzudecken. Und außerdem stirbt die professionelle Fotografie seit den 1980er Jahren langsam aus, sodass ich nicht sicher bin, ob sie noch viel länger ein bedeutender Markt bleiben wird.

Das war eine lange Einleitung, aber in einer Welt, in der jeder denkt, er könne ein Designer sein, ist es notwendig, die vollständige Liste der antagonistischen Design-Anforderungen restlos darzulegen, um diejenigen zu beruhigen, die glauben, sie seien der nächste Leonardo Da Vinci, und ihnen ein Gespür dafür zu geben, dass die simple Idee, die sie hatten, nur deshalb brillant erscheint, weil sie nicht die vollständige Spezifikationsnotiz haben. Ich hatte zu viele von ihnen in meinem Postfach und auf meinen Issue-Trackern.

Wie es in Ansel gehandhabt wird

Alle Screenshots wurden auf einem 15,6’’-Laptop erstellt.

Präsentation der globalen Module

Rufen wir uns zunächst in Erinnerung, wie die allgemeine Präsentation der Dunkelkammer neu gestaltet wurde:

• Modul-Tabs erhielten explizite Namen statt kryptischer Icons,
• Tabs sind (extern) in vorgeschlagener Workflow-Reihenfolge geordnet, von links nach rechts, sodass Nutzer nur der UI als Leitfaden folgen müssen,
• innerhalb der Tabs sind die Module in Pipeline-Reihenfolge geordnet (mit einer Ebenen-„über"-Logik, von unten nach oben), was auch die allgemein empfohlene Workflow-Reihenfolge ist. Der neue „Basis"-Tab ist eine Ausnahme, da er Modulsektionen hat: Innerhalb der Sektionen sind die Module pipeline-weise geordnet, aber die Sektionen selbst sind workflow-weise geordnet (wiederum Ebenen-„über"-Logik, also von unten nach oben),
• der „Pipeline"-Tab oder der nodale Graph der Modulreihenfolge macht alles eindeutig und zeigt eine direkte Ansicht der Pipeline-Knoten ohne zwischengeschaltete Umordnung,
• der „Favoriten"-Tab wurde vollständig entfernt, da er nur vorgibt, die Aufblähung zu lösen, indem er mehr davon hinzufügt.

Unterdessen wurden die zentralen Werkzeugleisten vollständig entfernt, was ein Maximum an Platz für Hochformatbilder freigibt, auf 16:9- und 16:10-Bildschirmen, wo vertikaler Raum wirklich kostbarer ist als horizontaler. Die Verwendung eines globalen Menüs hat es erneut erlaubt, viele merkwürdige Icon-Schaltflächen aus den Werkzeugleisten zu entfernen und sie durch explizite, textbasierte Menüeinträge zu ersetzen. Im Vollbildmodus verlieren Sie jetzt also nur die Höhe der globalen Menüleiste:

Optionen zum Überblenden und Maskieren wurden, da sie zwischen den Modulen vereinheitlicht sind, in die linke Seitenleiste verschoben. Das gibt viel vertikalen Platz für Module frei, verringert den Bedarf an internen Tabs und verhindert viel Herumklicken. Man beachte, dass die Überblendoptionen derzeit neu geschrieben werden, nachdem die Masken-API vollständig umstrukturiert, vereinfacht und erweitert wurde, sodass dies nur eine vorläufige Ansicht ist.

Ansel-Ansichten sind recht wortreich, daher wurde, um beim Unterscheiden zwischen konstantem Text (Beschriftungen) und Variablen (Werten) zu helfen, eine Syntaxfärbung eingeführt:

• konstante Beschriftungen sind weiß,
• variable Werte sind orange.

Farbkalibrierung

In der Farbkalibrierung wurden die 3 Reiter R, G und B in denselben Reiter Mixer zusammengeführt, der nun vollständig vertikal passt. Dasselbe gilt für Helligkeit, Buntheit und S&W, die nun in Ausgaben zusammengeführt sind.

Der Reiter Mixer hat nun 2 alternative GUI-Modi, zusätzlich zum typischen (jetzt vollständig genannt);

Die Ansicht Primärfarben wurde in das vorgelagerte Darktable übernommen, nur haben sie daraus ein eigenständiges Modul gemacht, was dumm ist: Die interne Pixel-Mathematik ist exakt eine 3×3-Matrixmultiplikation, was auch die Farbkalibrierung ist, also bestand keine Notwendigkeit für ein zusätzliches Modul. Auch dies ist ein Problem, das in der falschen Schicht gelöst wurde: Es brauchte eine zusätzliche GUI-Schicht in einem bestehenden Modul, sie haben daraus ein dupliziertes Modul gemacht.

Ansel hingegen implementiert es als GUI-Schicht, was bedeutet, dass die typischen Kanalmixer-Parameter hin und her in die Parameter der Primärfarben-Ansicht umgerechnet werden, und die Pixel-Mathematik des Moduls hat sich seit 2021 nicht geändert. Um eine vollständig invertierbare Transformation von der 3×3-Matrix zur Primärfarben-Ansicht zu gewährleisten, musste ein zusätzlicher Parameter Verstärkung hinzugefügt werden, um die Transformation mathematisch zu schließen.

Die einfache Ansicht ist etwas, das ich mehrere Jahre lang auf der langen Bank hatte: das nicht benutzerfreundliche Neuausdrücken der Mixer-Parameter in Form von Farbtonrotation, Chromaebenen-Streckung (Farbkontrast) und achromatischer Skalierung. Die U/V-Streckung ersetzt das alte Darktable-Modul Farbkontrast , das im CIE Lab 1976 arbeitet und die Chromatizität a und b geschoben/gezogen hat. Die einfachen Ansichten gehen weiter und lassen Sie Ihren eigenen uv-Chromatizitätsraum mithilfe der Rotation der Chroma-(uv)-Achsen definieren: Auf 0° gesetzt, ist u eine Grün-Magenta-Achse und v eine Blau-Gelb-Achse (ähnlich wie Farbkontrast). Aber dann können Sie sie drehen, wie Sie es brauchen, zum Beispiel wird bei etwa -20° die v-Achse einer Farbtemperaturachse recht nahe und die u-Achse der dazu orthogonalen Farbtonachse. Ich überlasse Sie der Dokumentation.

Dieser Modus eignet sich besonders gut, um überwältigendes blaues Bühnenlicht zu retten, sehr viel leichter als mit der typischen Kanalmixer-Benutzeroberfläche:

After

Before

1. durch Komprimieren der V-Achse komprimieren wir den Farbumfang stark auf der Blau-Gelb-Achse, was für den Rest des Farbumfangs sehr viel schonender ist als eine globale Chroma-Kompression,
2. durch Komprimieren der U-Achse komprimieren wir den Farbumfang auch auf der Magenta-Grün-Achse, aber sehr viel schonender,
3. der achromatische Kopplungsfarbton ist auf tiefes Blau gesetzt. Indem wir die Kopplungsstärke erhöhen, bilden wir einen Teil des Blaus auf die achromatische Achse ab, das heißt wir entsättigen und hellen es zugleich auf, was sehr dabei hilft, es zurück in den Farbumfang zu holen, während der Gesamteindruck von Blau erhalten bleibt. Umgekehrt wird die Komplementärfarbe abgedunkelt und wieder gesättigt, aber da diese Gegenfarbe Gelb ist und wir die Gelb-Blau-Achse über V komprimiert haben, landen wir am Ende ungefähr an derselben Stelle.

Dieses einfache Umschreiben der Koordinaten der Kanalmixer-Parameter ergibt also 6 Regler statt 9, und sie sind sehr viel aussagekräftiger und leichter zu steuern. Dies ist ein UX-Problem, das rein von der mathematischen Seite her angegangen wurde, denn es ist nichts weiter als das Neuausdrücken einer 3×3-Matrix in einer neuen orthogonalen Eigenvektorbasis, rotiert auf der achromatischen RGB-Achse, das heißt, es ging rein von einer linear-algebraischen Intuition aus. Aufgrund der Eigenschaften dieser neuen Eigenvektorbasis (die durch das Design vorgegeben sind) konnte ich Dimensionen entfernen und die verbleibenden in aussagekräftigere Regler verwandeln. Und das ist es, was ich meine, wenn ich immer wieder betone, dass man UX-Probleme nicht lösen kann, indem man bloß auf die GUI schaut.

Split-Toning RGB

Das alte Darktable-Split-Toning-Modul  arbeitete im HSL-Raum, der keine RGB-Codewerte größer als 1 unterstützt (also kein szenenbezogenes Arbeiten). Außerdem ist das Mischen von Farben in HSL wackelig und fühlt sich wie ein Spielzeug-Filter an, sobald man beginnt, die Einstellungen hochzudrehen.

Gleichzeitig geht das aktuelle Schema der chromatischen Adaptation in Ansel von einer einzigen Lichtquelle aus. Reale Szenen haben jedoch immer mindestens zwei Lichtquellen:

1. die Hauptlichtquelle, die die primäre Lichtquelle ist und hauptsächlich auf Lichter und Mitteltöne wirkt,
2. farbige Oberflächen, die Licht von der Hauptquelle reflektieren und einfärben, die als sekundäre Lichtquellen wirken und hauptsächlich von den Schatten bis zu den Mitteltönen wirken.

Bislang mussten Sie, um mit dieser Situation gemischter Lichtquellen umzugehen, Instanzen der Farbkalibrierung duplizieren und sie ein-/ausmaskieren. Aber der Versuch, eine binäre Maske zuzuschneiden (eine Region der einen Lichtquelle zugeordnet, der Rest der anderen Lichtquelle), ist fragil, weil er die um die Mitteltöne herum stattfindende Lichtmischung nicht berücksichtigt.

Das neue Split-Toning-Modul in Ansel bietet daher zwei Kanalmixer und zwei Farbtemperaturkorrekturen und dupliziert die neuen GUI-Modi der Farbkalibrierung. Es lässt Sie die Helligkeit jeder Lichtquelle definieren, ordnet jeder eine Farbmatrix zu und berechnet eine Mischung beider Matrizen, die auf jeden Pixel abhängig von seiner Luminanz angewendet wird.

After

Before

An dieser Stelle könnten Sie denken, ich sei besessen von Konzertfotografie, aber das liegt nur daran, dass Bühnenlicht das anspruchsvollste Setup ist und keinen Fehler in der Farb-Pipeline verzeiht. Diese Probleme waren jahrzehntelang ungelöst; blaue Lichter sind dafür bekannt, in Magenta zu kippen, und sie sind der ultimative Farb-Benchmark.

Hier haben wir die Temperatur der Lichter für natürlichere Hauttöne angepasst, während wir das insgesamt blaue Umfeld in den Schatten bewahrt haben. In einer solchen Szene gibt es kein Weiß, das Sie als Referenz nehmen könnten, sodass das Anpeilen natürlicher Hauttöne der einzige Anhaltspunkt ist. Dann tun Sie Ihr Bestes, um den Geist der Bühnenbeleuchtung zu bewahren (Blau blau halten), während Sie die Grenzen Ihres RGB-Farbumfangs im Auge behalten. Weitere Einzelheiten finden Sie in der Dokumentation.

Farb-Primärvalenzen

Wie ich bereits erwähnt habe, ist das Darktable-Modul Primärfarben eine bloße Dublette des Kanalmixers mit einer anderen Benutzeroberfläche. Aber es gibt Fälle, in denen das Bearbeiten des gesamten Farbraums über seine Primärvalenzen den niedrig gesättigten Bereich, der vollkommen in Ordnung war, zu sehr beschädigt. Es bestand also die Notwendigkeit, Primär- und Sekundärfarben (an den Ecken des Farbumfang-Würfels) auf eine Weise zu beeinflussen, die das Zentrum des Farbumfangs ausschloss, aber die Effekte dennoch sanft zwischen beiden Regionen überblendete und Bildverläufe bewahrte.

Dies wurde erreicht, indem in einem neuen Modul eine RGB-LUT aufgebaut wurde: Farb-Primärvalenzen.

After

Before

Dieses Beispiel wurde entworfen, um Rot und Orange weniger überwältigend zu machen, aber Blautöne dramatisch zu vertiefen, um zu zeigen, wie stabil die Farbtransformation entlang der Kanten zwischen unterschiedlich gefärbten Oberflächen ist.

Da das Modul intern dynamisch eine LUT aufbaut, indem es die Farbe von Kontrollknoten verschiebt, erhalten die Nutzer die Möglichkeit, über den Regler Farbumfang-Abdeckung zu entscheiden, wie weit von den Ecken des RGB-Würfels entfernt die Kontrollknoten sitzen. Dann erlauben 3 Glättungsparameter, die Farbverschiebungen in RGB mehr oder weniger stark zu überblenden und neutrale Farben mehr oder weniger vor der Verschiebung zu schützen. Schließlich verfügt das Modul über einen 3D-LUT-Betrachter:

Der LUT-Betrachter zeigt die Farbverschiebungen über den gesamten RGB-Würfel vom Ursprung bis zum Ziel. Er kann um die achromatische Achse gedreht (Azimut) oder in eine Chromatizitätsebenen-Ansicht versetzt werden (Achsenneigung = 90°). Er kann per Mausereignis in 3D gezoomt, verschoben und gedreht sowie geschnitten werden, um einen besseren Blick in einer bestimmten Tiefe zu erhalten. Schließlich kann die generierte 3D-LUT als .cube-cLUT-Datei exportiert werden, um in jeder Software, die diese unterstützt, wiederverwendet zu werden. Weitere Einzelheiten finden Sie in der Dokumentation.

Farb-Equalizer

Das Darktable-„Team" hat meinen zweiten (nicht funktionierenden) Prototyp  für den Farb-Equalizer genommen, nicht verstanden, warum er nicht funktionierte, Nachfilterungsschritte hinzugefügt, um die Probleme zu verbergen, und ihn veröffentlicht, als wäre es ihre eigene Arbeit, ohne mich auch nur ansatzweise zu nennen. Sie können ihn behalten: Er ist Mist. Und ich setze meinen Namen ohnehin nicht unter Mist.

Sehen Sie, das Problem dieses Prototyps ist, dass er die Sättigungsverschiebung im Farbraum dt UCS 22 HSB anwendete, den ich 2021 entworfen habe . Dieser Farbraum wird bereits in Farbbalance RGB für die Sättigung verwendet und zielt darauf ab, das richtige Maß an Abdunklung zu finden, das auf eine Farbe angewendet werden sollte, wenn man ihre „Sättigung" erhöht (eigentlich ihre Chroma, in strengen farbwissenschaftlichen Begriffen), um zu vermeiden, dass sie in unnatürliche Fluo- und Neonfarben degeneriert, was die typischen Fallstricke beim Hinzufügen von viel „Sättigung" sind. Statt der typischen Chroma-Einstellung, die die Buntheit bei konstanter Luminanz oder Helligkeit reduziert, dunkelt diese Sättigungsformel also auch ab. Und während das bei flachen Farbfeldern sehr gut funktioniert, besteht das Problem darin, dass Bilder keine flach gefärbten Oberflächen sind, sondern Verläufe haben.

Es wurde mir um 2022 herum gemeldet, dass die dt-UCS-HSB-Sättigung von Farbbalance RGB einen seltsamen achromatischen hellen Saum zwischen hellen, gesättigten gelben Herbstblättern und dem tiefblauen Himmel dahinter erzeugte. Das Problem war, dass sich an der Kante gelbes Licht von den Blättern und blaues Licht vom Himmel zu Achromatisch mischten (wie es sein sollte, da es sich um Komplementärfarben handelt), bedingt durch ein leicht unscharfes Objektiv oder atmosphärischen Dunst. Der Sättigungsalgorithmus dunkelte Gelb und Blau auf beiden Seiten des achromatischen Saums ab, aber nicht den Saum selbst, der nun heller hervortrat. Und dafür gibt es keine Lösung; es ist kein algorithmischer Fehler: Das Problem ist das Farbmodell, das die Wahrnehmung berücksichtigt, aber nicht die Lichtmischung. Ich war also ein weiterer Autor eines weiteren kaputten Farbraums, dessen Entwicklung mich Monate gekostet hat und 20 Stunden Rechenzeit, um die Parameter des Modells numerisch anzupassen.

Der Versuch, einen Farb-Equalizer unter Wiederverwendung desselben Farbraums zu implementieren, machte diese Probleme noch schlimmer, weil der Effekt nun farbtonweise gesteuert wurde, was Probleme auf zwei Dimensionen statt einer bedeutete. Um das Problem zu lindern, versuchte ich, die Dinge mit geführten RGB-Filtern zu glätten. Aber ich konnte die Zauberformel für eine ordentliche, robuste Überblendung nicht ganz finden. Da entschied das Darktable-Team, sich das schicke neue Ding aus dem Regal zu schnappen, und da verstand ich, dass dies nur in RGB geschehen konnte, wenn es ordentlich überblenden und Verläufe bewahren sollte.

After

Before

Der Farb-Equalizer erbt denselben interaktiven Cursor wie der Ton-Equalizer, für die direkte Bearbeitung am Bild durch Abtasten des Farbtons des Pixels unter dem Cursor, und das Scrollen aktualisiert automatisch den Graphen. Knoten können frei überall hinzugefügt werden, und vom interaktiven Cursor aus wird das Hinzufügen eines Knotens beim aktuellen Farbton per Rechtsklick erledigt.

Der Farb-Equalizer erlaubt es, eine farbtonweise Farbverschiebung für Schatten, Mitteltöne und Lichter zu definieren. Der Farbwähler erlaubt es zu sehen, wo eine Region zwischen den tonalen Reglern liegt. Dies ermöglicht eine sehr feinkörnige Steuerung, die zusammen mit derselben 3D-Glättung wie bei Farb-Primärvalenzen eine sehr robuste Methode zum Überblenden von Farbverschiebungen bietet. Das Chroma-Rauschen, das beim Definieren dramatischer Farbverschiebungen das Hauptproblem war, bei den alten Darktable-Farbzonen (die im CIE Lab 1976 arbeiten) oder beim vorherigen Prototyp des Farb-Equalizers, tritt nicht mehr auf.

Wie bei Farb-Primärvalenzen erzeugt dieses Modul dynamisch eine 3D-RGB-LUT, die genauso betrachtet und in .cube-Dateien gespeichert werden kann. Weitere Einzelheiten finden Sie in der Dokumentation.

Zeichnen

Muss ich noch mehr sagen?

Ansel implementiert nun ein Prototyp-Zeichenmodul, das es Ihnen erlaubt, Rasterbilder in einer szenenbezogenen Pipeline aus 32-Bit-Pinseln zu zeichnen, die HDR-Farben (>100 %) unterstützen. Pinsel unterstützen Deckkraft und Fluss (wie in Photoshop), zufällige Sprenkel, Pfadglättung, Kantenweichzeichnung und können in den Modi Malen, Radieren, Verwischen und Weichzeichnen verwendet werden. Pinselgröße, Deckkraft, Fluss und Härte können auf den Druck und die Neigung des Wacom-Stifts oder auf eine generische Cursor-Beschleunigung abgebildet werden. Sie verwenden korrektes vormultipliziertes Alpha und speichern Ebenen in 16-Bit-Gleitkomma-TIFF-Sidecar-Dateien, die in den meisten großen Zeichen-Apps bearbeitet werden können.

Mehrere Ebenen können verwendet werden, indem man mehrere Instanzen des Zeichnen-Moduls instanziiert und sie mit den generischen Ansel-Optionen zum Überblenden und Maskieren in das Bild einkomponiert. Es kann auch verwendet werden, um jede Art beliebiger Ebene aus jeder Software einzukomponieren, solange sie als 16-Bit-Gleitkomma als Ebene in der Ansel-TIFF-Sidecar-Datei gespeichert ist. Das Hintergrundbild (vor dem Modul) kann als Hintergrundebene exportiert werden, falls Sie ein Referenzbild benötigen, um in einer anderen Software zu zeichnen und das Ergebnis wieder zu importieren.

Möglich wurde dies durch die neue Pipeline-Architektur, die einen Echtzeitmodus ermöglicht hat. Zugegeben, es ist immer noch nicht so schnell wie Photoshop, denn bei jeder Aktualisierung eines Pinselstrichs laufen weitere Module nach Zeichnen in der Pipeline.

Das ist die ultimative Freiheit, alles zu erreichen, was Ihnen Knöpfe und Regler nie ermöglichen werden, sei es Abwedeln und Nachbelichten, das Reparieren beschädigter Teile (beschnittene Lichter, fehlende Bereiche) oder einfach das Vermischen von Fotografie und Malerei. Weitere Einzelheiten finden Sie in der Dokumentation.

Fotografisches Korn

Das alte Darktable-Modul Korn war wirklich unbefriedigend, da es nur Luminanz-Korn erlaubte und auf dem Helligkeitskanal des Farbraums CIE Lab 1976 angewendet wurde. Die Ergebnisse waren merkwürdig und entsprachen in keiner Weise Silberhalogenid. Ich habe endlich die stochastische Kornsynthese  implementiert, die ich 2023 in einem neuen Modul entwickelt habe: fotografisches Korn. Dieses teilt das Lichtfeld in virtuelle Silberhalogenidkristalle auf und simuliert Kornsensoren, die auf Schichten gestapelt sind. Es funktioniert gleichermaßen für S&W- und Farbkorn, obwohl ich mich von meinem ursprünglichen Artikel etwas distanzieren musste, um Farbe zu behandeln.

After

Before

After

Before

Filmic

Seit mehreren Jahren erzählen mir Leute, dass die dummen Darktable-Module sigmoid und das neuere AgX ihnen etwas mehr Kontrolle gäben. Und keiner von ihnen konnte mir genau sagen, Kontrolle worüber. Es hat mich also lange gekostet, das herauszufinden.

Sigmoid und AgX sind keine Revolutionen, sie sind weitere Filmics:

1. man konvertiert Farben mithilfe eines Logarithmus- oder Potenz-Shapers,
2. man klatscht eine S-förmige Kurve obendrauf,
3. dann tut man sein Bestes, um zu entwirren, was die Tonwertkurve während des gesamten Prozesses mit der Chroma angestellt hat,
4. und schließlich macht man den Shaper rückgängig.

Sigmoid und AgX hätten alternative Modi innerhalb von filmic sein können: Sie durchlaufen alle dieselben Schritte mit leicht unterschiedlichen Prioritäten und Strategien. Dies hätte ein einziges Modul für die Kompression des Dynamikumfangs geliefert, mit verschiedenen Modi, je nachdem, wie viel feinkörnige Kontrolle die Nutzer wollten. Stattdessen haben sie die Funktionalität dupliziert und GUI-Ballast hinzugefügt, sodass Nutzer nun zwischen Basiskurve (die bereits eine duplizierte & spezialisierte Variante der Tonwertkurve selbst war), filmic, sigmoid und AgX wählen müssen, um dieselbe Aufgabe zu erledigen, während keines davon tatsächlich die Funktionalität benennt, die es bereitstellt.

Das Eine, was filmic am besten kann, ist der explizite Umgang mit den Grenzen des Dynamikumfangs, was es erlaubt, es beim Drucken für die Schwarzpunktkompensation zu verwenden. Die beiden anderen behandeln sie als Nebenprodukt der Kontrasteinstellung. Da sich die Entwickler der beiden anderen nicht um Drucke scheren, können Sie darauf wetten, dass das einige Einschränkungen beim Design lockert und einige Regler in der GUI entfernt. Das Eine, was die beiden anderen besser machen, ist, manuelle Farbregler bereitzustellen, um Sättigungs- und Farbtonverschiebungsprobleme durch das Tonmapping hindurch zu entwirren, aber ich finde wirklich nicht, dass dieser Grad an Farbgranularität in eine Ton-Mapping-Funktion gehört: Es ist ein völlig verfehlter Workflow und eine verfehlte Funktionsaufteilung.

Jedenfalls habe ich schließlich herausgefunden, dass die feinere Kontrastkontrolle daher rührte, dass sigmoid direkt eine Steuerung der Knoten für Zehe und Schulter bereitstellt, während filmic eine globale Breite und Verschiebung verwendet, die umständlich zu bedienen ist, da sie beide koppelt. Dies war ursprünglich dafür ausgelegt, es auf die Datenblätter tatsächlicher Filmmaterialien abzubilden, weil die Breite eine reale Filmeigenschaft ist, um vielleicht eines Tages reale Filmmaterialien nachbilden zu können. Dieser Tag kam nie.

Also habe ich das Problem in der GUI-Schicht gelöst, indem ich eine Umrechnung zwischen den Einstellungen Breite/Verschiebung und Lichter/Schatten hinzugefügt habe, und nun erlaubt Ihnen filmic RGB, die Position der Zehe-/Schulter-Knoten direkt zu manipulieren:

Dabei wurde keine Pixel-Mathematik geändert, die Modulparameter sind immer noch dieselben wie zuvor, es wurde kein neues Modul erstellt, es ist lediglich ein zwischengeschalteter GUI-Umrechnungsschritt.

Schlussfolgerung

Alle neuen Module unterstützen die GPU-Auslagerung über OpenCL. Sie wurden auf Robustheit ausgelegt, und ich denke, dieses Ziel wurde erreicht. Sie haben schlechtere frühere Module ersetzt, die im CIE Lab 1976 arbeiteten und seit langem ihre Grenzen und Mängel gezeigt haben. Sie betreiben in Ansel nun eine vollständige RGB-Pipeline. Alte Module sind weiterhin im Programm und werden weiterhin für alte Bearbeitungen laufen. Außerdem sind die farbigen Regler und Farbton-Graphen mithilfe des Anzeige-Farbprofils farbmanaged.

Die Module, die ich kürzlich eingeführt habe, sind keine schicken neuen Spielzeuge, über die man in Begeisterung geraten sollte. Sie sind der Abschluss jahrelangen Nachdenkens über eine konsistente, kohärente Funktionsaufteilung, die dem szenenbezogenen Workflow hilft. Dieser szenenbezogene Workflow ist komplexer als der vorherige anzeigebezogene, schon allein weil wir „Weiß" normalisieren müssen, bevor wir in irgendeine LUT oder irgendeinen wahrnehmungsbezogenen Farbraum gehen, aber es ist der einzige Weg, HDR-Bilder, ordentliches Alpha-Blending für Masken und physikalisch korrekte Pixelfilter, die die Lichtmischung simulieren, anzugehen. Physikalisch korrekte Filter sind robust und erzeugen organische Ergebnisse, selbst wenn sie zu dramatischen Einstellungen getrieben werden. Aber sie sind für Neulinge oft weniger zugänglich und verstörend für erfahrene Retuscheure, die an Lightroom und dergleichen gewöhnt sind.

Dies wird mein letzter Beitrag auf dieser Website sein, denn ich ziehe mich aus der Entwicklung zurück. Sie hat mich zu viel gekostet: zu viel Stress, zu viele Burn-outs, zu viele Jahre, in denen ich den Mist anderer Leute ausgebügelt und unter ihren schlechten Entscheidungen gelitten habe. Ich bin müder, als Sie sich vorstellen können. Ich hasse das Programmieren und ich hasse Programmierer. Ich kenne nur sehr wenige von ihnen, die programmieren, um Dinge zu bauen oder Probleme zu lösen; die meisten genießen es einfach zu sehr, wertvolle Zeit mit einem Computer zu verbringen, und verwandeln sich in pyromanische Feuerwehrleute, denen man das Entwerfen von Dingen nicht anvertrauen kann. Ich hasse Technologie und sogenannte „Innovation": All das ist nur ein kapitalistischer Betrug, der auf unendliches Wachstum in einer Welt mit begrenzten Ressourcen ausgelegt ist, und wir tun so, als lösten wir durch Technologie geschaffene Probleme mit noch mehr Technologie. Das ist wahnsinnig. Die Open-Source-Welt erbt dieselbe Denkweise, einschließlich des Techno-Solutionismus , denn das ist die Art von Hirnfäule, die 350 Jahre Kapitalismus hervorbringen, obwohl FLOSS nicht die Profite hat, um das zu rechtfertigen. Sie ist voller Lügen und voller Mist, denn libre bedeutet Freiheit nur für Ingenieure, und die Nutzer können zur Hölle fahren. Das Problem ist, ich habe an diese Lügen geglaubt, an diese Werte: Sie waren (und sind immer noch) die meinen. Aber zu erkennen, dass sie nur leere Worte sind, die in toxischen „Communities" aus weißen Männern mittleren Alters mit B.Eng., M.Sc. und Ph.D. wiederholt werden, war ein brutales böses Erwachen. Was tun wir tatsächlich, um Nutzer zu befähigen, die es tatsächlich nötig haben? Ab welchem Punkt befähigt es irgendjemanden, der keinen Code lesen kann, wenn man beiläufig die Nutzung der CLI voraussetzt? Wir tragen nur dazu bei, die Kluft zwischen den computerkundigen Eliten und den Bauern zu vertiefen. Denken Sie daran, wir machen hier Fotografie-Software, keine Backend-Bibliothek, keine Server-Infrastruktur, sondern eine Endnutzer-Desktop-Anwendung.

Ich habe hier mein Hirn ausgeleert, um alles zu protokollieren, was ich über das Design von Bildverarbeitung gelernt habe, wie ich es gemacht habe und warum. Es ist wichtig zu verstehen, dass Nutzer und die meisten Entwickler nur wissen, wie sich eine Anwendung auf ihren eigenen Bildern verhält. Seit 8 Jahren habe ich viele pathologische Bilder erhalten, die mir Leute geschickt haben und die Mängel und Grenzen der Werkzeuge aufzeigen. Ich habe gerade jetzt etwa 45 GB dieser Bilder auf meiner Festplatte. Das gibt eine völlig andere Perspektive auf die tatsächlichen Probleme, als die, die alle fröhlichen Camper vielleicht haben: Ich bin der Typ, der weiß, was kaputtgeht und wann. Ich bin der Typ, den die Probleme finden. Ich bin die Kassandra  des Projekts. Und es ist lästig, sich ständig gegenüber Leuten, die die Probleme nicht sehen, rechtfertigen zu müssen, warum dieses Ding, das viel einfacher sein könnte, nicht viel einfacher sein kann, weil es pathologische Fälle gibt, in denen wir uns an die Variabilität der Eingaben anpassen müssen. Um sich an die Variabilität der Eingaben anzupassen, braucht man Nutzerparameter statt fest kodierter Konstanten. Daher GUI-Ballast. Die Art von GUI-Ballast, die man nicht vermeiden kann, ohne die Benutzbarkeit zu beeinträchtigen.

Man kann die Qualität eines Designs nicht beurteilen, wenn man seine Anforderungen nicht kennt. „Gefällt mir" oder „gefällt mir nicht" ist irrelevant. Niemand trägt gerne einen Sicherheitsgurt, es ist trotzdem gutes Design, wenn man bedenkt, wie viele Leben er gerettet hat. Jede echte Kritik kann nur darüber sein, wie die vorgeschlagene Lösung das Ziel erreicht hat, was nur möglich ist, wenn man das Ziel kennt. In der Bildverarbeitung macht es die gemischte Natur der Anforderungen schwer zu vermeiden, irgendwann in die Mathematik und ihre Hieroglyphen einzutauchen, und genau da verliert man die Leute. Aber das hält sie dennoch nicht davon ab, ihre nutzlose Meinung abzugeben, beginnend mit „Ich bin kein Programmierer"/„Ich bin kein Mathematiker"/„Ich bin kein Farbwissenschaftler"… „ABER"… [hier folgt irgendein zufälliges Hirnrauschen]. Open-Source-Code zu machen, wo alles öffentlich ist, lässt diese Art von Rauschen überall zu: Es ist wirklich ermüdend, und es gab viele Male, in denen ich mir wünschte, der Quellcode wäre geschlossen, nur um in Ruhe arbeiten zu können. Die meisten dieser Typen meinen es gut und wollen einfach Teil von etwas sein, aber zur Informationsüberflutung beizutragen hilft nicht und trägt nur dazu bei, Ermüdung zu erzeugen. Kommunikation ist der Ort, an dem jede Teamarbeit an Produktivität verliert

Bei Design geht es nicht darum, darauf zu hören, was den Leuten gefällt. Wenn 65 % Ihres Testpanels Text in Rot mögen und 72 % Text über rotem Hintergrund mögen, schreiben Sie dann roten Text über rotem Hintergrund? Das ergibt keinen Sinn. Wir machen keine Politik und versuchen nicht, Wähler während eines Wahlkampfs zufriedenzustellen, wir suchen nach langfristigen/zukunftssicheren Lösungen für Probleme. Bei Design geht es darum, darauf zu hören, was die Leute brauchen, was sie selten klar ausdrücken können, und Wege zu finden, diese Bedürfnisse zu faktorisieren. Die einzigen Statistiken, die zu berechnen sich lohnt, sind also die über die Anwendungsfälle: wie die Software genutzt wird, was die häufigsten Schmerzpunkte sind und was deren eigentliche Ursache ist. Dann behebt man die eigentliche Ursache, die weit weg von der tatsächlichen Erscheinungsform des Problems liegen kann. Auch das ist eine echte und wertvolle Fähigkeit: dem Faden des Problems zu folgen, durch Hinweise und Gerüche hindurch, um den wahren Ursprung aufzudecken, und nicht nur das End-Problem zu flicken oder es zu umgehen. „Auf Nutzer hören" bedeutet nicht, auf jeden Einzelnen zu hören und ihm zu geben, was er individuell will: Wir bieten keine Therapie an. Es bedeutet, auf die gesamte Nutzerbasis zu hören und die gemeinsam geteilten Bedürfnisse und Schmerzpunkte zu identifizieren, um eine faktorisierte Lösung zu ersinnen, die die meisten Bedürfnisse mit dem geringsten Maß an Technologie abdeckt. Das bedeutet nicht, jeden zu verwerfen, der um mehr als eine Standardabweichung vom Durchschnitt abweicht, aber diese Leute müssen möglicherweise auf Methoden zurückgreifen, die nicht maßgeschneidert und für ihre Bedürfnisse optimiert sind.

Design existiert nicht auf einer Insel: Es gibt andere Bildbearbeitungs-Apps ringsum. Es ist wiederum schwierig einzuschätzen, wann Ihr Design andere kopieren sollte, weil die Nutzer an deren UI-Semantik gewöhnt sein werden, und wann Sie abweichen sollten, weil das Problem, das Sie zu lösen versuchen, zu verschieden von dem ist, was die Konkurrenz macht, oder Ihr typischer Nutzer zu verschieden ist. Open Source ist ständig hin- und hergerissen zwischen der Versuchung, die kommerziellen Marktführer, die sie so innig hassen (aber insgeheim anzustreben), 1:1 zu kopieren, und der Gier, alle zu überlisten, während man das Rad neu erfindet (oft auf schlechtere Weise). In all dem ist Ihr Polarstern, sich jede Stunde jedes Tages zu fragen: Was ist das Problem, das wir zu lösen versuchen, und wer sind die Menschen, die damit konfrontiert sind? So können Sie die Dinge an Ihr Publikum anpassen, anstatt in Cargo-Kulte  zu verfallen und Lösungen zu übernehmen, weil sie in einem Kontext erfolgreich waren, den Sie nicht wirklich verstehen und der nicht unbedingt der Ihre ist.

Meine wichtigste Erkenntnis aus all diesen Jahren ist, dass das Anwenden von Farbtransformationen auf Pixel in irgendeinem anderen Raum als RGB zum Scheitern verurteilt ist, wie das Beispiel colorbalance RGB zeigt: Auch wenn es nach einer großartigen Idee klingen mag, die „Farb"-Arbeit (im Sinne von Farbton/Chroma) von der Tonwertarbeit zu entkorrelieren, wird es immer nur eine Frage sein, seinen Schmerz zu wählen. Das Erhöhen der Chroma bei konstanter Helligkeit degeneriert Farben in Fluo, das Erhöhen der Sättigung bei konstanter Helligkeit (also insgesamtes Abdunkeln) respektiert die Lichtmischungstheorie nicht, und beide erzeugen Chroma-Rauschen aufgrund der instabilen Natur der Farbtonwinkel. Aber dann ist RGB nicht wahrnehmungsgleichmäßig, und der grünliche Bereich jeder HSL/HSV-Farbtonskala nimmt etwa 30 % des Raums ein, während Grün nur 1/6 des wahrnehmungsbezogenen Farbtonrings ist. Die einzige Lösung ist, die GUI in wahrnehmungsbezogenen Farbmodellen zu handhaben und auf die eine oder andere Weise in RGB umzurechnen, bevor man sie auf Pixel anwendet. Was von den Entwicklern zusätzliche Abstraktionsgymnastik erfordert. Und das ist eindeutig nicht ihre Stärke, da das mathematische Niveau ziemlich niedrig ist.

Ich habe bereits einen Nachfolger, aber die Zukunft von Ansel wird eine Genossenschaft sein müssen, in der die Nutzer den Entwicklern faire Arbeitsbedingungen garantieren und die Entwickler den Nutzern garantieren, dass ihre Bedürfnisse abgedeckt werden, in gegenseitiger Verantwortung. Wir können nicht so weitermachen, es ist nicht gesund. Und mit „so" meine ich einerseits den „Hobby-Entwickler" mit null Verantwortlichkeit und andererseits den ausbrennenden Einzelentwickler, der unter der Armutsgrenze lebt, um die Dinge irgendwie zum Laufen zu bringen. Dieses Paradigma hat alles geliefert, was es konnte, es lässt sich nicht mehr optimieren. Dieselben Ursachen werden nur zu den Konsequenzen führen, die wir bereits kennen: Open Source ist beschissen. Wenn Sie mehr wollen, wird sich dieses Paradigma ändern müssen. Open Source ist auf der einen Seite eine Diktatur der Entwickler (derjenigen, die wissen und können) über die Nutzer (diejenigen, die es nötig haben), aber auf der anderen Seite ist es Ausbeutung derjenigen, die arbeiten, durch diejenigen, die nehmen. Das nährt nur gegenseitigen Groll, unterschwellige Verachtung und Bevormundung. Alle verlieren.

Die Alternative ist die derzeitige Verscheißerung der Konzernplattformen und der Technofaschismus, den sie derzeit ermöglicht. Sie sind gewarnt.