Hier im Forum ohne Streit? Das gehtmal garnichtschon garnicht in Technik & EBV.
UPS, glatt vergessen...
-
Neuer Gutscheincode unseres Partners Schutzfolien24:
DSLR-Forum2025
Dauerhaft 10% Rabatt auf alle Displayschutzfolien und Schutzgläser der Eigenmarken
"Upscreen", "Screenleaf", BROTECT" und "Savvies".
Der Code ist für alle Geräteklassen gültig. -
Ich freue mich bekannt geben zu können, dass das DSLR-Forum einen neuen Aktionspartner gewinnen konnte.
Saal Digital bietet Fotoprodukte in HighEnd-Qualität.
Für die Mitglieder des DSLR-Forums locken Rabatte und Sonderaktionen!
Alle Informationen dazu sowie ein tolles Einstiegsangebot unseres neuen Kooperationspartners gibt es hier. -
Mitmachen beim DSLR-Forum Fotowettbewerb Oktober 2025.
Thema: "Abendstimmung"
Jeden Monat attraktive Gewinnprämien, gesponsert von unserem Partner PixelfotoExpress.
Alle Infos zum Oktober-Wettbewerb hier! -
In eigener Sache!
Liebe Mitglieder, liebe Besucher und Gäste
ich weiß, es ist ein leidiges Thema, aber ich muss es ansprechen: Werbung, Werbeblocker und Finanzierung des Forums.
Bitte hier weiterlesen ... -
Nicht erreichbare Adressen im Benutzerkonto
Wir bekommen zurzeit eine große Anzahl an E-Mails, die das System zum Beispiel als Benachrichtigungen an Nutzer verschickt,
als unzustellbar zurück, weil z.B. die Adressen nicht erreichbar sind oder das Postfach gar nicht existiert.
Stellt doch bitte sicher, dass die Benachrichtigungen, die ihr vom System erwartet, auch zugestellt werden können.
Nicht erreichbare E-Mail-Adressen sind dazu wenig hilfreich.
Danke!
WERBUNG
Lightroom -- Kataloggrösse
- Themenersteller Bezier
- Erstellt am
UPS, glatt vergessen...
meiner ist auch so gross - mit 40.000 Bildern
Bezier
Themenersteller
Alle Achtung! Hast Du das reverse-engineered? (Was immer das auf Deutsch heißt.)
Nein, so weit geht mein Ehrgeiz dann doch nicht. Ich verwende LR jetzt seit mehr als 4 Jahren und hatte mich für die Kataloggröße bisher nie interessiert, bis ich gestern zufällig gesehen habe, wie riesenhaft das Teil ist. Meine Vermutung, dass LR bei mir Amok läuft und den Katalog auf das hundertfache eigentlich benötigte Volumen aufbläht, scheint sich aber aufgrund der Berichte hier im Thread nicht zu bewahrheiten. Und wenn dort ernsthaft ganze XML-Dateien (selbst schon ein schauderhaft fülliges Format) hineingestopft werden, wundert mich sowieso nichts mehr...
Gruß
Bezier
Gast_129296
Guest
Die Nutzungsdauer ist wohl einer der Treiber für die Grösse der Datenbank, dann die Entwicklungshistorie wird natürlich vorgehalten.
Zudem ist bei einer Datenbank die Grösse der Datein <> Nettodatenmenge, denn die Datenbank muss ja immer Platz reservieren und zusätzliche Verwaltungsinformationen mitführen.
Wenn Du wissen willst, welche Daten den Platz beanspruchen, dann kannst Du mir einem Tool wie SQLite Browser die Tabellen als CSV exportieren.
Dann hast Du auch einen Blick auf die Netto Datenmenge, ich würde die bei Dir auf ca 650-700 MB schätzen.
Ja, manuell
Du solltest Dir auch Sqlite Browser anschauen ;-)
Wenn Dein Backup bei 0,9 GB 20 Min. dauert, ist nicht Lightroom Dein Problem.
Gruß
Klaus
Gast_129296
Guest
Wenn das so lange dauert, was hast Du für einen Rechner ?
Das klingt nach einem CPU oder IO Engpass.
Bezier
Themenersteller
Ich bin ein bekennender Vertreter der aussterbenden Spezies jener, die der Meinung sind, dass elektronische Geräte durchaus länger als drei Jahre genutzt werden können, und habe einen 8 Jahre alten Laptop. Den ich auch noch mindestens zwei weitere Jahre einsetzen möchte. Und ich habe in meinem Leben genug systemnahen / embedded Code geschrieben, um zu wissen, dass eine solche Maschine prinzipiell mehr als leistungsfähig genug ist, für alles, was ich damit machen möchte. Wenn denn die verwendete Software effizient geschrieben ist, wovon man heute ja generell nicht mehr ausgehen kann.Wenn Dein Backup bei 0,9 GB 20 Min. dauert, ist nicht Lightroom Dein Problem.
Nicht das eigentliche Backup, sondern vor allem die Optimierungsphase dauert so lange. Klar, dass das mit einer SSD (der Prozessor ist hier nicht der Engpass) schneller ginge. Aber auch klar, dass es sehr viel schneller ginge, wenn die DB um den Faktor 100 kleiner wäre, oder?
Natürlich braucht eine DB auch Speicher für sich selbst. Es ist mir ja auch völlig egal, ob pro Bild nun 100, 500 oder 800 Bytes gespeichert werden. Aber 80.000, im Durchschnitt wohlgemerkt -- so weit reicht mein Vorstellungsvermögen dann doch nicht...
Gruß
Bezier
Das weiß ich doch - und wir hatten ja auch schon regen Kontakt miteinander in dem dazugehörigen Thread ;-)
Gast_129296
Guest
Dann hat man allerdings nicht den Intigritätscheck den SQLITE durchführt.
Auch wird der Katalog dann nicht optimiert, also auch nicht verkleinert, falls entsprechend Platz frei geworden ist.
Das kann man ja einmal im Quartal machen, daran wirds ja nicht scheitern denke ich.
mfg
cane
Bezier
Themenersteller
Ich bin, was Backups angeht, da eher der "doppelt gemoppelt hält besser"-Typ. Natürlich werden sowohl der aktuelle Katalog wie auch die von LR erzeugten Backups nach Änderungen jeweils noch auf eine externe Platte kopiert, und ca. einmal monatlich noch auf eine weitere externe Platte. Von LR erzeugte Backups, die älter sind als ein Jahr, lösche ich dann ab und zu manuell.
Ausserdem werden die Bearbeitungen jeweils noch als .xmp exportiert. A propos: Obwohl die .xmp-Dateien als XML-Strukturen zu 95% aus überflüssiger Information bestehen (Leerzeichen, lange und ständig wiederholte Tag-Namen, ASCII-Zahlen usw.) sind die bei mir "nur" zwischen 16 und 64 kBytes gross. Also wesentlich kleiner als die Katalog-Datenbank pro Bild, von der man doch eigentlich eine viel grössere Effizienz erwarten würde...
Gruss
Bezier
Ausserdem werden die Bearbeitungen jeweils noch als .xmp exportiert. A propos: Obwohl die .xmp-Dateien als XML-Strukturen zu 95% aus überflüssiger Information bestehen (Leerzeichen, lange und ständig wiederholte Tag-Namen, ASCII-Zahlen usw.) sind die bei mir "nur" zwischen 16 und 64 kBytes gross. Also wesentlich kleiner als die Katalog-Datenbank pro Bild, von der man doch eigentlich eine viel grössere Effizienz erwarten würde...
Gruss
Bezier
Aber der Katalog hält auch alle Presets,Entwicklungshistorie (vor allem die frißt Platz, da auch alle Exports festgehalten werden),Sammlungen pp. und dazu kommt noch, dass dann die XML Struktur so in die DB geschrieben wird. Einfach nicht effektiv
ciao tuxoche
.. Katalog mit dem Explorer sichern ...
Mag sein; ich hab diese Funktion noch nie genutzt. Dann würde bei meinen Daten der Katalog noch kleiner werden?
Mag sein; ich hab diese Funktion noch nie genutzt. Dann würde bei meinen Daten der Katalog noch kleiner werden?
Man könnte die Zuordnungen schon so speichern, allerdings müsste man dann bei der Suche nach einem bestimmten Schlagwort alle Bilddatensätze betrachten.
Lightroom speichert die Daten in einer Schlagwort-Bild-Tabelle, die sowohl für das Bild, als auch für das Schlagwort eine ID und noch eine ID für den Datensatz (die man nicht zwangsläufig braucht) beinhaltet.
Dazu kommen noch Indizes, die eine schnelle (logarithmische) Suche in der Zuordnungstabelle ermöglichen.
Der Grund dafür, dass die Datenbank so groß wird, ist allerdings die Menge der Bearbeitungsschritte, die Lightroom bei jeder Änderung und jedem Exportvorgang als neuen Datensatz ablegt.
In jedem dieser Datensätze ist neben Metadaten der komplette Bearbeitungsstand als String (!) gespeichert (durch Komma getrennte Key-Value Paare) und beinhaltet neben den rechts im Entwicklungsmodul zur Verfügung stehenden globalen Reglern natürlich auch Informationen über die lokalen Anpassungen.
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.
WERBUNG