Lightroom -- Kataloggrösse

[Bezier]

In jedem dieser Datensätze ist neben Metadaten der komplette Bearbeitungsstand als String (!) gespeichert (durch Komma getrennte Key-Value Paare)

Ehrlich? Das ist ja komplett irre... Wer denkt sich denn so etwas aus?

Spätestens, wenn man mit dem Korrekturpinsel arbeitet und nach jedem gezogenen Pinselstrich den kompletten Bearbeitungsstand (zusätzlich zu jedem vorherigen) gespeichert bekommt, wird klar, dass der Platzbedarf pro Bild quadratisch mit der Zahl der Pinselstriche wächst und die Datenbank dementsprechend sehr schnell sehr groß werden kann.

Allerdings... Das heisst also, immer mit möglichst wenigen Bearbeitungsschritten auszukommen versuchen, oder? Es geht ja nicht nur bzw. sogar eher weniger um den Speicherplatz, aber all die Daten wollen ja auch geschrieben, gelesen und verarbeitet werden.

Wenn ich beim Bearbeiten in der History ein paar Schritte zurückgehe und dann auf einem früheren Stand sozusagen neu anfange, gilt das dann auch als zusätzlicher Bearbeitungsschritt? D.h. wäre es besser, in so einem Fall "Undo" zu verwenden? Oder werden hier vernünftigerweise die überflüssig gewordenen alten Bearbeitungsschritte tatsächlich gelöscht?

Gruss
Bezier

 

[Bezier]

Man könnte die Zuordnungen schon so speichern, allerdings müsste man dann bei der Suche nach einem bestimmten Schlagwort alle Bilddatensätze betrachten.

Was bei einer Datenbank mit ein paar zehntausend Zeilen auf einer Maschine, die 500'000'000 Befehle pro Sekunde ausführen kann, ja noch nicht wirklich ein Problem wäre.

Aber mir ging es ohnehin nicht darum, ob es nun 4, 8 oder 12 Bytes sind (schon klar, dass eine DB auch Verwaltungs-Overhead hat), sondern darum, wo die durchschnittlich(!) 80'000 herkommen. Was Du weiter unten in Deinem Beitrag ja erschreckend beantwortet hast.

Gruss
Bezier

 

[Manni1]

Wenn ich beim Bearbeiten in der History ein paar Schritte zurückgehe und dann auf einem früheren Stand sozusagen neu anfange, gilt das dann auch als zusätzlicher Bearbeitungsschritt?

Bei meiner Arbeitsweise (s. oben) geh ich davon aus, daß die Versuchsarbeiten weggeworfen werden, wenn ich die gefundenen Berabeitungen aufs ursprüngliche Bild anwende. Schließlich sehe ich die verworfenen Schritte ja auch nicht mehr in der History.

Ich hab's mit dem KISS-Prinzip - keep it small & simple ...

 

[Gast_129296]

Ehrlich? Das ist ja komplett irre... Wer denkt sich denn so etwas aus?

Das ist nicht irre, wie sollte sonst ACR was mit den LR Entwicklungen anfangen können ?
Adobe sichert so die Kompatibilität zwischen den eigenen Konvertern, ich vermute, das ist der Grund. LR ist ja nicht auf der grünen Wiese entstanden, zum einen muss man also XML für ACR liefern können, zum anderen in LR erweiterte Historsierung anbieten.
Man kann ja aber vorher nicht wissen, welcher Stand denn mal als XML geschrieben und von ACR genutzt werden soll.

Im Übrigen, was hat man vorher gemacht, als RAW geöffnet, dann all die Dinge die jetzt in LR gehen in PS oder woanders gemacht und sich ein 50 MB grosses TIFF zusätzlich aufgehalst. Für mehrere Versionen auch mehrere davon.

Da ist das hier der ökonomischere Weg. Ein ernsthaftes Problem ergibt sich daraus nicht wirklich.

Und - wie gesagt - die Historie kann ja gelöscht werden.

 

[Bezier]

Man kann ja aber vorher nicht wissen, welcher Stand denn mal als XML geschrieben und von ACR genutzt werden soll.

Es würde ja genügen, bei jedem Schritt die dort erfolgten Veränderungen in der History zu speichern, anstatt bei jedem Schritt alle bis dahin erfolgten Veränderungen noch einmal (und noch einmal, und noch einmal, ...) zu kopieren. Und man bräuchte das ganze auch nicht als String zu speichern, der viel mehr Platz benötigt und bei jeder Verwendung wieder neu geparst werden muss.

Wenn Du eine Überweisung tätigst, werden in der DB der Bank ja auch nur die für diese Überweisung wichtigen Information neu gespeichert, und es werden nicht noch einmal alle Überweisungen kopiert, die Du seit Kontoeröffnung vorgenommen hast. Das weiss ich zufällig ganz genau ;-)

Ein ernsthaftes Problem ergibt sich daraus nicht wirklich.

Verglichen mit dem, was einem sonst so im Leben passieren kann, ist ein um den Faktor 100 überflüssigerweise zu grosser Speicherverbrauch in einer Bildverarbeitungs-Software natürlich tatsächlich nicht sehr ernsthaft...

Nun gut, ich gehöre halt einer Dinosaurier-Generation an, die noch 200 Byte grosse Programme geschrieben hat, die etwas Sinnvolles getan haben. Wer unter 50 ist, wird das kaum noch nachvollziehen können. Und ich habe mich schon immer gefragt, warum LR auf den heutigen fantastisch-schnellen Maschinen derart grottenlangsam ist. Es gibt nämlich in den meisten Fällen einfach keinen technischen Grund dafür. Aber wenn man Grössenordnungen an überflüssiger Rechenzeit einbaut, bekommt man natürlich jede Maschine ausgebremst.

Anyway, mein Ursprungsproblem ist ja beantwortet: Diese Datenbankgrössen sind bei LR normal, und ich habe dank ghost0cnc sogar eine Vorstellung bekommen, warum das so ist.

Gruss
Bezier

 

[Bezier]

Bei meiner Arbeitsweise (s. oben) geh ich davon aus, daß die Versuchsarbeiten weggeworfen werden, wenn ich die gefundenen Berabeitungen aufs ursprüngliche Bild anwende. Schließlich sehe ich die verworfenen Schritte ja auch nicht mehr in der History.

Ich hab's mit dem KISS-Prinzip - keep it small & simple ...

Das mache ich auch so. Bin nur nicht sicher, ob die Daten dann wirklich aus der DB verschwinden. Über "Undo" kann ich sie ja wieder zurückholen, und falls "Undo" auf der gleichen Struktur arbeitet...

Was ja auch kein Problem wäre, wenn jeder Bearbeitungsschritt nur ein paar, oder allenfalls ein paar dutzend, Bytes hinzufügen würde.

Gruss
Bezier

 

[rodinal]

Mag sein; ich hab diese Funktion noch nie genutzt. Dann würde bei meinen Daten der Katalog noch kleiner werden?

M.W. löscht sqlite Daten erst wirklich, wenn ein "vacuum"-Befehl ausgeführt wird. Dann muss aber die ganze Datei neu sortiert und geschrieben werden- das dauert. Ich würde trotzdem nicht darauf verzichten. Das DBMS ist ja eigentlich eher für Telefonlisten oder SMS gedacht und kann bei grösseren Datenmengen schnell anfällig oder ineffektiv werden, wenn es nicht regelmässig optimiert wird.

 

[Manni1]

Über "Undo" kann ich sie ja wieder zurückholen

meines Wissens nicht, nachdem man LR beendet & neu gestartet hat - habs grad probiert - nur Änderungen der aktuellen Session lassen sich zurücknehmen.

M.W. löscht sqlite Daten erst wirklich, wenn ein "vacuum"-Befehl ausgeführt wird.

Ja - klar. Und was ist so ein Befehl
Kenn mich bloß mit Oracle aus.

 

[pfeffi]

M.W. löscht sqlite Daten erst wirklich, wenn ein "vacuum"-Befehl ausgeführt wird. Dann muss aber die ganze Datei neu sortiert und geschrieben werden- das dauert. Ich würde trotzdem nicht darauf verzichten. Das DBMS ist ja eigentlich eher für Telefonlisten oder SMS gedacht und kann bei grösseren Datenmengen schnell anfällig oder ineffektiv werden, wenn es nicht regelmässig optimiert wird.

Ja - klar. Und was ist so ein Befehl
Kenn mich bloß mit Oracle aus.

Gerade getestet - SQLite löscht direkt.

Beim Löschen wird aber der Platz in der Datenbank nicht freigegeben, der ominöse Befehl gibt ihn dann wieder frei

Vgl. hierzu: https://sqlite.org/lang_vacuum.html

 

[Bezier]

Und der Befehl wird dann wohl bei Durchführung der LR-Katalog-Optimierung aufgerufen. Was auch erklären würde, warum die (zumindest auf einem Fast-1-GB-Katalog-nicht-auf-SSD) so lange dauert.

Edit: Gerade in der Beschreibung des Vacuum-Befehls weitergelesen: Ja, während der LR-Katalog-Optimierung wird definitiv die dort erwähnte temporäre Datenbank-Datei erzeugt.

Gruss
Bezier

 

[NaumannU]

Gerade getestet - SQLite löscht direkt.

Beim Löschen wird aber der Platz in der Datenbank nicht freigegeben, der ominöse Befehl gibt ihn dann wieder frei

Das Verhalten ist nicht DB-untypisch (viele DB-Systeme ticken so oder ähnlich) und durchaus gewollt.

Dazu muss man man drüber nachdenken wie Datenbanken intern arbeiten. Da sind einerseits die reinen Datentabellen, die nicht oder nur nach einem Primärschlüssel sortiert sind. Dann gibt es noch Indizies, die nach bestimmten Kriterien sortiert sind und Verweise auf die eigentlichen daten beinhalten.

Bei einem Insert von Daten muss das DB-System die an der richtigen Stelle "einschieben", dazu muss es an dieser Stelle in den Tabellen und Indizies Speicherplatz allozieren. Wenn das irgendwo "mittendrin" ist, dann ist dieses Allozieren recht rechenintensiv. Wenn schon freier Speicher vorhanden ist, dann kann der einfach und mit wenige Aufwand genutzt werden.

Um dies zu ermöglichen wird eben Speicher von gelöschten Daten nicht sofort freigegeben.

Ergo: Man kann sich auch zu Tode optimieren. Ständiges Komprimieren der DB kann im Betrieb kontraproduktiv wirken, weil das DB-System dann bei jedem Insert/Update erst wieder zeitaufwändig Platz in den Index-Trees und/oder Tabellen schaffen muss um die Verweise bzw. Daten an der richtigen Stelle einfügen zu können.

 

[kalle-knips]

Wenn Dein Backup bei 0,9 GB 20 Min. dauert, ist nicht Lightroom Dein Problem.

So sehe ich das auch... Mein Katalog (60.000 Bilder und 1,67 GB) ist in handgestoppten zwei Minuten und zwölf Sekunden gesichert.

 

[Georgius]

Aber nicht mit der LR-Funktion.

 

[Gast_129296]

Bei einem Insert von Daten muss das DB-System die an der richtigen Stelle "einschieben", dazu muss es an dieser Stelle in den Tabellen und Indizies Speicherplatz allozieren. Wenn das irgendwo "mittendrin" ist, dann ist dieses Allozieren recht rechenintensiv.

IdR wird mit Freelists in Blöcken gearbeitet, eine Tabelle kann sich über beliebig viele Blöcke oder Seiten erstrecken. Wenn Platz gebrauht wird, wird irgendwo hingeschrieben und verwiesen.

Ist die Dateigrenze erreicht, dann wird erweitert oder eine neue Datei hinzugefügt.


Bei Indices ebenso, die fragmentieren ( ebenso wie Tabellen ) mit der Zeit und ein Reorg kann ab und an sinnvoll sein.

Um dies zu ermöglichen wird eben Speicher von gelöschten Daten nicht sofort freigegeben.

Das hat eher damit zu tun, das man hierzu defragmentieren müsste, und das geht eben nur durch Neuanlage der ganzen DB ( Vacuum bei SQLITE), daher auch die Temp DB, oder internes kopieren der Tabellen.

 

[km28]

Nun gut, ich gehöre halt einer Dinosaurier-Generation an, die noch 200 Byte grosse Programme geschrieben hat, die etwas Sinnvolles getan haben.

Tja, die Zeiten sind lange vorbei. Ich glaube, heute kann kaum noch einer den Begriff "Assembler" passend zuordnen. Und auch C und seine Folgevarianten werden nur noch zum geordneten Aufruf von komplexen und damit entsprechend großen und langsamen Funktionen/Objekten genutzt.

Gruß
Klaus

 

[Wiegald]

...
Und ich habe mich schon immer gefragt, warum LR auf den heutigen fantastisch-schnellen Maschinen derart grottenlangsam ist. Es gibt nämlich in den meisten Fällen einfach keinen technischen Grund dafür. Aber wenn man Grössenordnungen an überflüssiger Rechenzeit einbaut, bekommt man natürlich jede Maschine ausgebremst.
...

Ja die damaligen Algorithmen in doppelter Flieskommagenauigkeit bei 16MB Raw in nahezu Echtzeit waren schon was.
Lightroom nutzt eine recht komplexe Pipeline für die Bearbeitungsstufen und die fordert ihren Tribut.
Die Datenbank ist ein großartiges Mittel alle Schritte zu speichern und rückgängig zu machen. Das ist der konsequent zuendegedachte Weg der Nicht-Destruktiven und reversiblen Bearbeitung.

Es gibt eine Möglichkeit, mit der man die komplette Historie zu jedem Bild löschen kann. Damit sollte sich die DB verkleinern lassen, aus meiner Sicht wäre das der erste Schritt.
Mit einem Plugin kann man vorher noch Snapshots erstellen. Gibts von Friedl ... Name gerade nicht präsent.

 

[kalle-knips]

Aber nicht mit der LR-Funktion.

Falls das auf meinen Beitrag bezogen war: Doch!