KI-generierte Zwischenergebnisse der Raw-Entwicklung spielen in Lightroom eine zunehmend wichtigere Rolle, und Adobe sucht weiterhin nach dem besten Ort, diese zu speichern. Version 15 von Lightroom Classic hat schon wieder eine Veränderung gebracht, und besser als zuvor ist es schon, aber noch immer nicht optimal – oder doch?

Vermutlich ist es eine Konsequenz des Abomodells, dass sich Adobe an die beste Umsetzung einer guten Idee erst herantasten muss. Früher verging zwischen kostenpflichtigen Lightroom-Upgrades, die neue Features brachten, eine längere Zeit. Das verschaffte den Entwicklern die nötige Muße, herauszufinden, wie sich eine neue Funktion optimal mit dem Rest der Software verzahnen ließ. Nun, da die Kunden monatlich zahlen, verlangen sie auch einen steten Strom inkrementeller Upgrades, und so wird eine Neuentwicklung, kaum funktioniert sie im Prinzip und bringt einen offensichtlichen Nutzen, sogleich ausgerollt. Ihre endgültige Gestalt findet sie aber manchmal erst später, nachdem die Nutzer ihre Unzufriedenheit mit der ersten Version geäußert hatten. So ist es auch mit den diversen KI-Funktionen geschehen, die es in Lightroom mittlerweile gibt.

Um zu erklären, warum die KI-Funktionen überhaupt Probleme machen, muss ich etwas weiter ausholen. In der konventionellen, destruktiven Bildbearbeitung passierte früher genau das: Man bearbeitete ein Bild. Man malte neue Pixel und entfernte andere mit dem digitalen Radiergummi, fügte ein Bild in ein anderes ein, hellte Tonwerte auf oder dunkelte sie ab, veränderte die Farben, verschob Pixel an einen anderen Platz und so weiter. Man arbeitete mit einem Raster von Pixeln und ersetzte vorhandene Pixel durch andere, bis einem das Ergebnis gefiel. (Nicht nur) Photoshop führte dann Ebenen, Masken, Einstellungsebenen und andere Konzepte ein, mit denen auch eine nicht destruktive Bildbearbeitung möglich wurde, aber die destruktive Bearbeitung einer aus Pixeln bestehenden Fläche bildete noch immer und ist bis heute die Grundlage.

Ein Raw-Konverter arbeitet vollkommen anders. Es gibt überhaupt kein hochaufgelöstes Bild, das man bearbeiten könnte, sondern nur die Rohdaten aus einer Raw-Datei und die vom Anwender gewählten Parameter, die steuern, wie daraus ein Bild entwickelt werden soll. Die Raw-Entwicklung kann man sich wie eine Fabrik vorstellen, in der aus Rohstoffen in einer Kette von Arbeitsstationen, die in einer vorgegebenen Reihenfolge durchlaufen werden, die fertigen Produkte entstehen. Ganz grob kann man jedes Bedienfeld des Entwicklungsmoduls einer Arbeitsstation zuordnen, und dessen Regler steuern, was dort geschehen soll. Wann immer man irgendeinen Regler verstellt, durchläuft ein Teil der Rohdaten die Kette der Entwicklungsstationen, und das Ergebnis ist ein aktualisiertes Vorschaubild. Dabei arbeitet man nie mit dem ganzen Bild in voller Auflösung: Die Vorschau zeigt entweder nur einen Ausschnitt des Bildes oder das ganze Bild in reduzierter Auflösung. Deshalb kann die ständige Neuberechnung so schnell erfolgen, dass wir an einem Regler ziehen und ohne merkliche Verzögerung den Effekt unserer Aktion sehen. Erst beim Export des Ergebnisses wird das vollständige Bild in voller Auflösung berechnet; das nimmt dann mehr Zeit in Anspruch, geschieht aber im Hintergrund, so dass wir im Vordergrund bereits mit dem nächsten Bild weiterarbeiten können.

Das Problem: KI ist schön, macht aber viel Arbeit

Mit den neuen, KI-basierten Funktionen ließ sich diese Konzept nicht mehr so kompromisslos beibehalten. Das galt insbesondere für Adobes KI-Demosaicing-Verfahren, das feinste Details besser bewahrt, weniger Farbartefakte erzeugt und dabei auch noch optional entrauschen oder das Bild per Superresolution auf die vierfache Auflösung skalieren kann. Ein Durchlauf durch das mit Myriaden von Fotos trainierte neuronale Netz dauert sehr lange, bei leistungsschwächeren Computern auch mehrere Minuten, so dass es nicht in Frage kam, das neue, bessere Demosaicing einfach statt der konventionellen Methode in die Kette der Verarbeitungsstationen zu integrieren. Nach jeder Änderung irgendeiner Reglerstellung hätte man eine gefühlte Ewigkeit warten müssen, bevor das Ergebnis im Vorschaubild zu sehen gewesen wäre.

Adobe baute das KI-basierte Verfahren daher als Menübefehl »Verbessern« ein, mit dem man aus dem Ergebnis des KI-Demosaicing eine neue Version der Raw-Datei erzeugte – eine lineare DNG-Datei, wobei „linear“ in diesem Zusammenhang bedeutet, dass sie für jedes Pixel vollständige RGB-Daten enthält. Während in den Raw-Dateien aus der Kamera typischerweise 14 Bit pro Pixel stehen, die nur über jeweils eine der drei Grundfarben Auskunft geben, enthält eine lineare DNG-Datei 48 Bit pro Pixel – je 16 Bit pro Farbkanal. Abgesehen vom darin schon „eingebackenen“ Demosaicing, also der Rekonstruktion der fehlenden Farbinformationen aus den Nachbarpixeln, sind die Daten darin aber immer noch relativ roh, und sie lassen einem fast alle gewohnten Freiheiten, sie zum fertigen Bild zu entwickeln. Wenn man vor dem »Verbessern« bereits verschiedene Entwicklungseinstellungen vorgenommen hatte, wurden diese in die DNG-Datei übernommen, ließen sich aber auch noch ändern. Da das aufwendige Demosaicing per KI ja bereits abgeschlossen war, wurde das Vorschaubild weiterhin verzögerungsfrei aktualisiert. Damit war das Problem gelöst – oder etwa doch nicht?

Obwohl Lightroom die Daten vor der Speicherung der DNG-Datei noch einmal verlustfrei komprimierte, war die verbesserte lineare DNG-Datei um 50 bis 150 Prozent größer als das Original, womit der Speicherplatzbedarf auf ein Vielfaches stieg – die Originaldatei wollte man ja auch noch behalten. Es empfahl sich daher, »Verbessern« erst ganz zum Schluss anzuwenden, nachdem das Bild ansonsten bereits optimal entwickelt war. Dann konnte man das verbesserte Bild exportieren und die DNG-Datei gleich wieder löschen. Falls man später doch noch einmal etwas ändern wollte, konnte man sie ja neu anlegen. So brauchte man letztendlich nicht mehr Platz auf der Festplatte, aber das Prozedere gestaltete sich umständlicher. Störend war auch, dass man schon vor dem »Verbessern« die Stärke der Entrauschung wählen musste; überlegte man es sich später anders, musste man die KI erneut starten.

Lightroom Classic 14.4: Geht’s nicht kleiner? Oh ja!

Während sich die Anwender langsam an den neuen Workflow gewöhnten, blieben die Lightroom-Entwickler nicht untätig. Sie fanden schließlich eine neue, platzsparende Methode, das Ergebnis des KI-Demosaicing zu speichern, und in Lightroom Classic 14.4 wurde diese eingeführt. Tatsächlich konnte der Platzbedarf auf ein Bruchteil der Größe einer linearen DNG-Datei beschränkt werden. Bei meinen Bildern habe ich eine Reduzierung bis auf ein Zwanzigstel beobachtet, und in jedem Fall nahmen die zusätzlich gespeicherten Daten deutlich weniger Platz als die Originaldatei in Anspruch. Wie das gelang, ist nicht ganz klar; eine verlustfreie Komprimierung wurde ja schon vorher angewandt und hätte auch nicht so effektiv sein können. Eine verlustbehaftete Komprimierung schon, nur wäre sie auf Kosten der Detailzeichnung gegangen, die das KI-Demosaicing (samt Entrauschen und gegebenenfalls Superresolution) ja verbessern sollte – das wäre kein gangbarer Weg gewesen. Es ist nur eine Spekulation, aber ich vermute, dass Lightroom die Differenz des verbesserten Bildes zur konventionell interpolierten Version berechnet: Die pixelweisen Unterschiede werden meist gering und in strukturarmen Bildbereichen sogar gleich Null sein, und solche Daten lassen sich auch mit verlustfreien Verfahren sehr effektiv komprimieren. Am Ende muss Lightroom nur das Differenzbild dekomprimieren und zum konventionellen Resultat addieren, um das verbesserte Bild zu rekonstruieren – beides geht blitzschnell.

Nachdem der Speicherbedarf auf ein akzeptables Maß reduziert war, wollte Adobe auf die zweite (DNG-) Datei verzichten und die Verbesserung zusammen mit der originalen Raw-Datei speichern, womit sie den gewohnten, einfacheren Workflow wiederhergestellt hätten. Aber wo sollten die beim KI-Demosaicing gewonnen Daten bleiben? Zunächst einmal im Katalog, in dem alle Entwicklungsdaten eingetragen werden. Der Katalog im engeren Sinne ist eine Datei mit der Endung „lrcat“; das ist eine SQLite-Datenbank, die die aus den Bilddateien ausgelesenen Exif- und IPTC-Metadaten enthält, die von Lightroom selbst erzeugten Metadaten wie Schlagwörter und Bewertungen, und natürlich die eigentlichen Entwicklungseinstellungen.

Schaltet man in den Katalogeinstellungen die Option ein, automatisch auch XMP-Daten zu speichern, werden dieselben Metadaten auch in einem Textformat gespeichert, entweder – wenn es um eine Raw-Datei im DNG-Format geht – in der Raw-Datei selbst, ansonsten in einer Sidecar-Datei mit demselben Namen, aber der Endung „XMP“. Diese redundante Speicherung ist nicht zwingend nötig, aber sie bietet unter anderem den Vorteil, dass man bearbeitete Raw-Dateien mitsamt aller Entwicklungseinstellungen, Schlagwörtern etc. auf einen anderen Computer übertragen kann – man muss dazu nur neben der Raw-Datei die XMP-Datei kopieren. Die zur Verbesserung nötigen Daten ließen die XMP-Dateien seit Version 14.4 anschwellen, von den gewohnten wenigen Kilobyte auf mehrere Megabyte. Dasselbe passierte mit der lrcat-Datei des Katalogs, in der ja dieselben Daten – nur in anderer Form – gespeichert waren.

Die KI-gestützten Funktionen waren damit zwar nicht schneller geworden und ließen sich noch immer nicht in die Kette der Verarbeitungsstationen integrieren, aber da man nur noch mit der originalen Raw-Datei arbeitete, wurde der Menübefehl »Verbessern« überflüssig. Das KI-basierte Demosaicing, Entrauschen und Skalieren wurden dafür als weitere Optionen dem Bedienfeld »Details« hinzugefügt. Wählte man eine von ihnen aus, musste man warten, bis die KI ihren Job erledigt hatte, aber die Stärke des Entrauschens ließ sich danach noch ändern, und da die eigentliche Arbeit ja schon getan war, sah man im Vorschaubild sofort, was das bewirkte. Die KI-Funktionen konnten auch in das Kopieren und Einsetzen von Entwicklungseinstellungen einbezogen werden. Fügte man sie bei einer größeren Zahl weiterer Bilder ein, nahm es längere Zeit in Anspruch, jedes der Bilder individuell mit der KI zu bearbeiten, aber wenigstens musste man dabei nicht zuschauen, sondern konnte einen Kaffee trinken gehen. Vor Version 14.4 hätte man das Entrauschen jeder Datei einzeln anstoßen müssen.

Auch andere KI-Funktionen erfordern die Speicherung ihrer Ergebnisse. Wenn Sie die KI für eine lokale Bearbeitung Masken des Motivs, des Himmels oder einzelner Personen erzeugen lassen, analysiert ein für diese Aufgabe trainiertes neuronales Netz das Bild, was so viel Zeit erfordert, dass man diese Prozedur nicht bei jeder Neuberechnung des Vorschaubildes wiederholen möchte. Dasselbe gilt für das generative Entfernen. Auch diese Daten müssen also dauerhaft gespeichert werden, und das geschah zunächst im Katalog und gegebenenfalls in XMP-Dateien.

Lightroom Classic 15: Hey, die Daten sind weg … aber nein, da sind sie ja!

Insgesamt ging Lightroom Classic 14.4 zwar sehr viel schonender mit dem Speicherplatz um, als es die Vorversionen getan hatten, aber die Verfettung der lrcat-Datei und der XMP-Dateien gefiel manchen Anwendern nicht, und auch den Entwicklern war sie ein Dorn im Auge. Mit Version 15 führte Adobe nun eine weitere Änderung ein, die den Platzbedarf allerdings nicht wirklich reduziert – die Zwischenergebnisse der KI werden lediglich woanders gespeichert. Die XMP-Dateien sind nun wieder auf eine Handvoll Kilobyte geschrumpft, und Adobes Diät lässt auch die lrcat-Datei verschlanken, die ja dieselben Daten enthält. Aber was ist mit den Daten passiert, die sie so fett gemacht hatten? Neben den Raw-Dateien tauchen neuerdings zusätzliche Sidecar-Dateien mit der Endung „ACR“ auf, sofern man die Option zur Speicherung von XMP-Dateien gewählt hat. „ACR“ steht für „Adobe Camera Raw“, obwohl das gleichnamige Photoshop-Plug-in hier gar nicht im Spiel ist, und diese Dateien enthalten die KI-Daten, die zwischen den Versionen 14.4 und 15 in den XMP-Dateien Platz gefunden hatten. Viel gewonnen ist damit nicht, denn der Speicherbedarf ist nicht kleiner geworden und man muss lediglich mit noch mehr Dateien hantieren – die XMP-Dateien gibt es ja weiterhin.

Und was ist mit dem Katalog, in dem die KI-Daten ebenfalls enthalten sein müssten? In der lrcat-Datei findet man sie nicht mehr, aber das ist ja nicht die einzige Katalogdatei. Geht man danach, welche Datei innerhalb des Katalogs sich ändert, wenn man entrauscht, dann scheint es die Previews.lrdata-Datei (eine weitere SQLite-Datenbank) zu sein, in der neben Vorschaubildern nun auch alle KI-Daten landen. Dies ist ohnehin die größte der Katalogdateien, und sie wird nun eben noch größer. Es hilft also nichts: Man kann die von den KI-Funktionen erzeugten Daten anderswo verstecken, aber verschwunden sind sie damit noch lange nicht. Sie werden ja gebraucht, und wer die höchst nützlichen KI-basierten Features anwenden will, muss als Preis den – immerhin nur noch moderaten – zusätzlichen Speicherplatzbedarf akzeptieren.

Wird es dabei für immer bleiben? Sobald komplexe KI-Modelle von unseren Computern so schnell angewandt werden können wie heutzutage das Nachschärfen oder eine Farbkorrektur, wird keine Zwischenspeicherung mehr nötig sein. Man lässt die KI einfach alles neu berechnen, wenn sich irgendetwas ändert. Andererseits: Bei mir als Informatiker sträubt sich eigentlich alles dagegen, aufwendige Berechnungen unnötig oft auszuführen. In der Softwareentwicklung hat man es oft mit einem Trade-off zwischen Rechenaufwand und Speicherplatzbedarf zu tun: Wenn man mehr Zwischenergebnisse speichert, spart man damit CPU-Zyklen (oder in diesem Fall eher GPU-Zyklen), muss dafür aber einen erhöhten Speicherplatzbedarf in Kauf nehmen. Alles in allem scheint mir die aktuell in Lightroom verwirklichte Lösung gar kein so schlechter Kompromiss zu sein. Wer es anders sieht, muss auf Fortschritte in der Hardware-Entwicklung hoffen.