Lightroom Katalogoptimierung mal anders

Es gibt ja verschiedene Lösungsansätze, den Lightroom Katalog zu optimieren bzw. letztlich Lightroom schneller zu machen.

Ausgangslage

Die Vorschläge reichen hier von der selbstverständlichen Speicherung des Kataloges und der Vorschaudateien auf einer [post id=108]SSD[/post] bis hin zur Aufteilung des [post id=2549]Kataloges[/post] in mehrere je nach Shooting oder nach Jahren.

Egal welchen Ansatz man verfolgt ist der Katalog von Lightroom zunächst mal eine Datenbank, in der Lightroom Stichwörter, GPS-Daten, virtuelle Kopien aber vor allem Bearbeitungsschritte am Bild festhält.

Hintergrund

Bereits in dem Artikel über [post id=2443]virtuelle Kopien und Schnappschüsse[/post] in Lightroom bin ich schon einmal auf das Entwicklungsprotokoll in Lightroom eingegangen.

Lightroom hält dabei jede Veränderung am Bild fest, sei es, dass ich das Bild exportiert habe, oder die Sättigung z.B. um 10 erhöht habe. Aber auch wenn ich anschließend die Sättigung noch um weitere 5 Einheiten verändere, erzeugt das wiederum einen Eintrag in der Datenbank.

Da Lightroom ein Non-Destruktiver RAW-Konverter ist, liegt der Vorteil einer solchen Vorgehensweise auf der Hand. Ich kann die Entwicklungsparameter eines Bildes zu jedem Zeitpunkt auf einen bestimmten Schritt zurücksetzen.

Wie ich finde bequemer geht es aber mit virtuellen Kopien, wenn man hinsichtlich der Entwicklung eines Bildes etwas ausprobieren möchte. Dies gilt grundsätzlich bei mir für die s/w Varianten eines Bildes und wenn man z.B. mit extremen Kontrasten oder anderen extremen Einstellungen arbeiten möchte.

Wenn ich mir dann allerdings anschaue, wie die Informationen in  der Datenbank gespeichert werden, dann wundert mich der enorme Platzbedarf überhaupt nicht mehr. Hier wird das XML-Format der [post id=2069]XMP-Dateien[/post] im Klartext in der Datenbank gespeichert, ohne z.B. für sich wiederholende Einträge meinen Namen mit ID’s zu arbeiten, die dann über dies ID verknüpft nur einmal in einer anderen Referenztabelle im Klartext stehen.

Aber vielleicht macht diese platzraubende Struktur es den Programmieren einfacher, den Wust aus Entwicklungseinstellungen,Presets und sonstigen Voreinstellungen in den Griff zu bekommen, auch vor dem Hintergrund, dass heutzutage ein paar hundert MB Speicherplatz selbst auf einer SSD nicht die Welt kosten.

Aktion

Aber genau in dieser ungünstigen Struktur bzw. Art der Speicherung der Daten in der Datenbank liegt der Schlüssel zu einer erheblichen Größenreduzierung der Datenbank. Mein Hauptkatalog enthält ca. 20.000 Aufnahmen und ist 813.690.880 Bytes groß. Lösche ich alle Protokoll-Einträge dann reduziert sich die Größe auf 507.157.888 Bytes und die Reduzierung ist schon erheblich. Aber zur Vorgehensweise, alle Bilder markieren (wer viel mit gestapelten Bildern arbeitet, dran denken alle Stapel vorher einzublenden) und dann in das Entwicklungsmodul wechseln. Dort unter Entwickeln -> Protokoll löschen die Protokolle löschen. Vorher sollte aber in jedem Fall eine Sicherung des Kataloges erfolgen.

Fazit

Die Methode reduziert die Kataloggröße nicht unerheblich und virtuelle Kopien werden dadurch nicht beeinflusst (außer natürlich deren Entwicklungsschritte), ob dadurch aber Lightroom merklich schneller wird, bezweifle ich. Wer mit Schnappschüssen anstatt virtuellen Kopien arbeitet, um gewisse Entwicklungsstände eines Bildes zu speichern, der sollte diese Methode nicht versuchen, weil die durch die Protokolllöschung ebenfalls verloren gehen.

Was denkt ihr über eine solche, relativ radikale Methode? Ist es die Größenreduzierung wert? Hinterlasst mir doch eure Kommentare und gerne auch Fragen.

ciao tuxoche