Lightroom Classic 15.0 ist da

[RobiWan]

Scheinbar, weil ich das Verzeichnis mit LRC geöffnet habe.

So kann ich es nicht bestätigen. Ich habe ein verzeichnis besucht und genau 1 Datei bearbeitet. Für diese eine Datei hat LR dann eine *.acr Datei angelegt.

 

[Photonenverhunzer]

Der Varianz-Regler bei Punktfarbe ist meines Erachtens derzeit eines der interessantesten Features des neuen LrC.

so weit
Maico

 

[MichaelN]

Irgendwie verstehe ich diese Funktion nicht. Hat jemand ein Beispiel was man damit machen kann?

 

[Photonenverhunzer]

Hier wird es gut erklärt

Ich hab das selbst an einer Blüte probiert und finde die Korrektur der wirklich kniffligen Farbe sehr gut zu händeln. Lichtnelken haben so ein wirklich intensiv irisierendes Farbspektrum, daß für mein Empfinden Sensoren sehr fordert.


so weit
Maico

 

[brontes]

Das Problem ist ja folgendes : die KI Bearbeitung kann nicht nur als Schritt in dem Katalog gespeichert werden. Natürlich ginge das, aber beim erneuten ausführen kommt ein anderes Bild heraus. Jeder der schon mal das KI Entfernen ausprobiert hat, weiß das.

Bei KI entfernen gebe ich dir Recht. beim entrauschen nicht. Das Entrauschen kann jederzeit mir gleichem Ergebnis wieder hergestellt werden. Mal ganz abgesehen davon sind die KI-Entfernungsdaten in Summe nicht wirklich sehr groß, da sie zum einen wohl bei den wenigsten Bildern verwendet werden und zum Andern nur einen kleinen lokalen Teil des Bildes ausmachen.
Bei mir gehört das Entrauschen zum Standardprozess mit dazu. Daher sind die zusätzlichen anfallenden Daten im Katalog schon erheblich!

 

[yosemite]

Der Varianz-Regler bei Punktfarbe ist meines Erachtens derzeit eines der interessantesten Features des neuen LrC.

Ja, da stimme ich gerne zu. Ich hab ein 15 Jahre altes Bild rausgekramt, bei dem ich mit dem Polfilter "etwas" übertrieben hatte. Schon erstaunlich wie man mit dem Varianz-Regler den unschönen dunklen Bereich angleichen kann. Aber da gibt es sicherlich noch diverse andere Beispiele (siehe auch diverse YT-Videos).

 

[ewm]

Noch was zu den neuen Features:

https://www.dpreview.com/articles/3559947371/adobe-max-2025-photoshop-lightroom-photography-tools?utm_source=self-desktop&utm_medium=marquee&utm_campaign=traffic_source

 

[Photonenverhunzer]

Auch nett für Freunde rustikaler Sensorvernachlässigung:

so weit
Maico

 

[ewm]

Ich experimentiere gerade mit LrC 15 auf meinem MacbookAir M1.

Teststellung:

- mehrere Ordner mit ca. 5000 Fotos liegen auf meinem NAS
- NAS ist über WLAN angebunden, Transferrate zum Macbook ca. 30MB/s
- Fotos in LrC importiert
- Smart Previews generiert, die entsprechende Katalogdatei "Lightroom Catalog Smart Previews.lrdata" ist ca. 5,5 GBgroß
- der Katalog liegt auf dem internen SSD des MacbookAir


Aufgabe:

- ein Backup des Katalogs nimmt ca. 200MB ein, ermittelt beim Backup auf der internen SSD
- das Backup auf die interne SSD ging blitzschnell
- Katalog und Backup sollen aber nicht auf dem gleichen Datenträger liegen
- das Backup des Katalogs soll also aufs NAS erfolgen

Jetzt das Rätsel:

- die Datenrate beim Backup aufs NAS beträgt ca. 600kB/s -> es dauert ewig
- die vor dem Start des Backups abgefragten Optionen "Integrität" testen und "Katalog nach dem Backup" optimieren haben keinen Einfluss. Egal ob Haken drin oder nicht

- der Export eines Tiffs, ca. 150MB als Schreibtest in den gleichen Backup- Ordner des NAS erfolgt dagegen mit der bei gleichen Transferrate wie beim Import, also ca. 30MB/s

Nur ein Backup des Katalogs auf NAS geht so ars...langsam, dass ich nach mehr als 5 Minuten abgebrochen habe.
Ich habe das mehrmals versucht, mehrmals LrC neu gestartet, den Rechner neu gestartet
Es blieb immer bei ca. 600kB/s


Bitte keine Diskussionen um die Sinnfälligkeit, LrC auf dem Macbook zu betreiben und die Fotos via WLAN vom NAS zu holen. Das war nur ein erster Test, funktioniert mit den Smart Previews aber ganz ordentlich, soll aber dennoch meinen stationären Arbeitsplatz mit iMac nicht ersetzen.

Für Tips zum lahmen Backup auf NAS wäre ich dankbar.

 

[MichaelN]

Mach das Backup lokal und kopier es dann aufs NAS

 

[0zwo11]

Wäre auch mein Vorschlag.

Hab ebenfalls keine guten Erfahrungen in Sachen Geschwindigkeit gemacht, wenn LrC direkt aufs NAS sichert - aber auch schon vor 15.x

Mein Katalog liegt auf der externen SSD, die Sicherung geht auf die interne SSD von dort per GoodSync automatisch bei Veränderungen aufs NAS.

 

[ewm]

Danke an Euch beide

Ich habe das Gefühl, dass sich LrC da mit dem Zippen der Katalogdaten auf dem NAS schwer tut.

Das Zippen kann man aber nicht abschalten, oder???

Wenn nicht, dann wird halt lokal gesichert und kopiert. Auf meinem Hauptsystem geht das Backup auf eine externe SSD und wird alle paar Tage auf NAS gesynct. Kann sein, das mir das deshalb vor LrC 15 noch nicht aufgefallen ist.

 

[dadri]

Mal ein paar Worte zu den ACR Daten um die Missverständnisse zu bereinigen:

ACR-Dateien sind einfach Sidecar Dateien wie XMP. Wer mit Sidecars arbeitet erhält die Daten aus den Katalogdateien/Ordnern in XMP+ACR zum Bild, wer ohne Sidecars arbeitet hat die Daten nur in den Katalogdateien/Ordnern (aber einen speicherplatzfressenden Bug weniger).


Vor LrC 14.4:

• wurden für KI-Entrauschen u.a. KI-Operationen DNG-Kopien zum RAW angelegt.
• Die zum DNG-gehörigen Entwicklungs- und Metadaten wurden wie bei jedem DNG/Bild im LR Katalog gespeichert, die KI-Rohdaten nicht.
• Alle Folgeschritte (Auswahl/Bewertung/Metadaten/Bearbeitung) mussten ggf. explizit auf DNG + RAW angewandt werden, da LR sie zwar stapelt aber nicht als "ein Bild" behandelt.
  • Löscht man die DNG verliert man alle anderen Schritte daraus auch.
  • Nutzt man die KI-Funktionen zum Schluss hat man keine guten Ergebnisse, denn gerade bei Entrauschen wirklich stark rauschender Bilder ändert sich der Farbeindruck u.U. maßgeblich und auch KI-Masken für Objekte oder Farben werden davon beeinflusst.
• Die DNG beinhaltet mindestens die KI-Ergebnisse, die XMP-Entwicklungs- & Metadaten. Es war meist mehr als 2x so groß wie das RAW selbst. Eine Extraktion des original-RAWs war aber nicht vorgesehen, was aus Backup-Sicht für Monks die gerne Originale behalten wollten nervig war.
• Jede Einstellungsänderung an der Entrauschintensität erfordert eine neue DNG Berechnung/Erzeugung.

Mit LrC 14.4:

• wurden für KI-Entrauschen u.a. KI-Operationen die berechneten Rohdaten in einer separaten KI-Blob-Katalogdatei (wie bei Previews) gespeichert.
• wurden die KI-Rohdaten zusätzlich in den XMP Dateien gespeichert, wenn man mit XMP Dateien arbeitet.
• wurden - wenn man mit XMP Dateien arbeitet - (vermeintlich durch einen Bug oder eine unglückliche Fügung) die KI-Rohdaten zusätzlich überflüssigerweise in die eigentliche Katalogdatei gespeichert (wie wohl alles aus der XMP mit dem Katalog synchron gehalten wird).
• Man hatte nur ein Bild ohne Kopie.
  • Gedanken um Folgeschritte entfallen (außer ggf. Überlegungen zur besten Aktions-Reihenfolge aus Performanc-Gründen)
  • Backup-Monks hatten es einfach
  • Jeder Folgeschritt (und sei es ein neu hinzugefügtes Stichwort) erforderte ein neu Schreiben der nun riesigen XMP, wenn man mit XMP arbeitet. Besonders spaßig für Batch-Operationen auf 100+ Bildern.
• Einstellungsänderung an der Entrauschintensität konnten jederzeit angepasst werden.
• Die XMP-Dateien wuchsen meist von 10-15 kB auf 2-3 MB pro Bild.
• Die KI-Rohdaten wurden platzsparender als bei den DNGs gespeichert aber ineffizienter als von CameraRAW, weil die Binärdaten in Textdaten (für das XMP) konvertiert werden mussten.

Mit LrC 15:

• werden weiterhin für KI-Entrauschen u.a. KI-Operationen die berechneten Rohdaten in einer separaten KI-Blob-Katalogdatei (wie bei Previews) gespeichert.
• werden die KI-Rohdaten zusätzlich in den ACR Dateien gespeichert, wenn man mit XMP+ACR Dateien arbeitet.
• Man behält die Vorteile aus 14.4. (Nur eine Bilddatei, Folgeschritte unproblematisch, Intensität nachträglich zu ändern)
• Es entfällt die fehlerhafte Speicherung in der Katalogdatei.
• Folgeschritte gehen auch wenn man mit XMP+ACR arbeitet wieder schnell, denn dazu müssen wie früher nur die kB kleinen XMPs aktualisiert werden.
• ACRs werden effizienter codiert gespeichert, sodass XMP+ACR kleiner sein müsste als XMP aus 14.4.
• Die Methode ist besser kompatibel zu CameraRAW, was schon zuvor ACRs erstellt hat.

...Wie machst Du das zukünftig? Komplette mehrfache Backups der RAW-Dateien incl. ACR-Sidecars?
...

Lustig wirds da auch für 3rd-Party-Anbieter, wie Lr/TImelapse, die bisher verlässlich rein über die XMP-Dateien mit LrC kommunizieren konnten.
...

ad 1) Backup-Strategie bleibt 1:1 wie prä-LrC 14.4. Egal ob mit oder ohne Sidecar Files.
ad 2) 3rd-Party Anbieter hatten bisher die Welt mit KI-Daten in XMP nur für wenige Monate. Der Weg bleibt genau der gleiche. Sie können sich über wieder/weiterhin schlanke XMPs freuen. Mit den KI-Daten können sie likely eh nichts anfangen egal ob im XMP, ACR und/oder Katalog gespeichert.

... Ich denke aber schon, dass Adobe letztendlich im Katalog nur zusätzlichen Verweis auf weitere Sidecar Dateien einfügt. Ist sie da, wird sie gelesen, ist sie nicht da... wird sie eben nicht gelesen.
...

Nein. Wie immer hat der Katalog Vorrang. Bei erkannten Konflikten zwischen Katalog und XMP/ACR müsste man als User explizit anklicken, dass die Dateien neu eingelesen werden sollen und die Katalogdaten überschreiben sollen oder aus dem Katalog neu gespeichert werden sollen um die XMP/ACR zu überschreiben.

...
Wenn diese riesige Datenmenge jetzt sowohl im Katalog als auch in einer ACR- Datei abgespeichert werden würden, dann wäre das aus meiner Sicht ein gewaltiger Nachteil.

Da diese RAW- Verbesserung + optional Entrauschen beim Demosaicing, also am Anfang der RAW- Bearbeitung stattfindet, wäre eine, aus irgendeinem Grund fehlende ACR- Datei kein Beinbruch. LrC könnte die bei jedem Aufruf des Fotos neu generieren.
...

Die riesige Datenmenge wurde zuvor an 1 oder 3 Stellen (durch einen Bug oder besser gedacht durch fehlendes Zuende-Denken von Adobe in 14.4) und werden jetzt nur noch an 1 oder 2 Stellen gespeichert - abhängig davon ob man Sidecars aktiviert.

Wenn ich das abgewählt habe (XMPs werden hier manuell geschrieben/gelesen für Lr/Timelapse), dann landen die ACR-Daten weiterhin im Katalog?

Die landen afaik in jedem Fall weiterhin "im Katalog". Nicht mehr doppelt, also nicht mehr in der lrcat-Datei aber weiterhin im lrcat-data Ordner daneben. (LR mag manuelle Löschaktionen in dem Ordner übrigens nicht so richtig gerne.)

Das habe ich leider auch beobachtet. Die ACR-Datei ist damit redundant, so wie auch die XMP-Datei redundant ist.
...
Am liebsten wäre mir, wenn Lightroom die Entrauschungsdaten nur im ACR-Speichert, so dass man die jederzeit wieder erzeugen könnte. Die ist ja an sich redundant wenn die Information dass das Bild entrauscht werden soll im Katalog und in der XMP stehen würde.

Vom Konzept des zentralen Katalogs wird sich Adobe bestimmt nicht lösen IMO. Ist auch performanter als immer auf die Sidecars zuzugreifen.
Aber es gibt in der Community einen Vorschlag von einem anderen User, analog zur automatischen Preview-Bereinigung auch sowas für die lrcat-data Daten im Katalog einzuführen. Kommt das deinem Wunsch nahe? Vielleicht upvoten, wenn es dir hilft:
https://community.adobe.com/t5/ligh...cally-cleaned-up-like-previews/idc-p/15565433

So ganz verstehe ich die "Kritik" an den ACR Dateien nicht.
Die kann man nicht in XMP schreiben, weil es binäre Werte sind und XMP wird u.U nicht nur von Adobe gelesen/geschrieben. Weiter geht es darum, dass Adobe schon vor einigen Monaten dies für die Bearbeitung in ACR eingeführt hat. Ergo man hat jetzt LR zu ACR wieder kompatibel gemacht.
Man muss doch nicht unbedingt XMP schreiben lassen.

Absolut!
Genau genommen wurden sie aber eben gerade bisher in die XMP geschrieben (umkonvertiert von binär zu Text). Jetzt ist die LR-Welt wieder etwas ordentlicher.

 

[0zwo11]

Ich habe das Gefühl, dass sich LrC da mit dem Zippen der Katalogdaten auf dem NAS schwer tut.

Ist schon etwas her, dass ich mich ins Thema eingelesen hatte: daher bitte überprüfen.
Aus der Erinnerung: der Kopiervorgang über SMB läuft nicht garantiert vollständig oder gar nicht.
Bei Cache- und / oder Verbindungsfehlern kann so eine unvollständige Sicherung entstehen, die du erst bemerkst, wenn du sie brauchst.
Interne / externen SSD sind ohne Netzwerk-Protokoll verbunden und damit File-Locks synchron.
An der grundsätzlichen Betrachtung seitens Adobe dürfte sich damit auch in 15.x nichts geändert haben.

 

[MichaelN]

Ich tendiere dazu die xmp/acr zu deaktivieren. Ich schreibe die seit Anbeginn der Zeit - und habe die nie benötigt. Früher hat es nur Zeit gekostet, aber nun auch spürbar Speicherplatz

 

[brontes]

Vom Konzept des zentralen Katalogs wird sich Adobe bestimmt nicht lösen IMO. Ist auch performanter als immer auf die Sidecars zuzugreifen.
Aber es gibt in der Community einen Vorschlag von einem anderen User, analog zur automatischen Preview-Bereinigung auch sowas für die lrcat-data Daten im Katalog einzuführen. Kommt das deinem Wunsch nahe? Vielleicht upvoten, wenn es dir hilft:
https://community.adobe.com/t5/ligh...cally-cleaned-up-like-previews/idc-p/15565433

Danke für den Link.
Mit dem internen Aufbau der Katalogdatei habe ich mich bisher nicht näher beschäftigt. Wenn ich das nun richtig verstanden habe werden die Vorschauen und die KI-Entrauschungsdaten dort in den blob-Dateien gespeichert.
Daher könnte man ja überlegen seinen Katalog ohne blobs zu speichern. Bzw. die blobs aus dem Zip entfernen. Das würde ich mich nicht trauen. Ich weiß ja nicht was da noch alles drin steht.
Es mag ja auch sein, dass die Entrauschungsdaten im Katalog "schneller" durch LrC nutzbar sind. Allerdings dauert das Lesen einer ACR-Datei nun auch keine Welten. Zumindest nicht wenn die ebenfalls auf einer SSD des Rechners lagern.

Vielleicht wäre es ja auch ein guter Weg, wenn Adobe zur Sicherung des Kataloges anbieten würde diesen ohne KI-Entrauschungsdaten und ohne Vorschauen zu sichern. Und dann die Option anbieten würde bei Bedarf diese bei Fehlen wieder herzustellen. Damit könnte ich auch gut leben.

 

[Klabauter.Mann]

Heutige Rechner gestatten doch die üppige Ausstattung mit nvme, notfalls via USB 3.2x2 oder TB4 o.ö. auch extern. Und 2TB nvme sind nicht wirklich teuer. Nun hat mein Katalog noch deutlich 1-stellige GB bei ca. 130.000 Fotos und exzessivem Entrauschen in den letzten Jahren.

Wo seht Ihr da ein Problem, dass man Platz sparen muss? LrC fluppt bei mir mehr als zufrieden stellend, einzig die GPU könnte vielleicht noch einen deutlichen Schub bringen. Aber auch da sollte man mit einer 5060TI/16GB kein Undergog sein. Lange Rede, kurzer Sinn - lohnt das ganze Hirnschmalz, ob/wie/wenn/wo/wieviel Daten man da aus Adobes Konstrukt eventuell raus sezieren kann? Wenn man die Hardware eingermaßen aktuell hält, sehe ich auch in "riesigen" Katalogen derzeit kein Problem.

 

[MichaelN]

Das ist durchaus ein Punkt den man ebenfalls mit in Erwägung ziehen sollte. Ein verrauschtes, schlechtes Foto gelöscht und schon hat man den Speicherplatz für die Entrauschung eines guten eingespart.

 

[Klabauter.Mann]

Ich nutze regelmäßig die Tage um Weihnachten/Sylvester zum Aussortieren. Alle mit "P" ehemals ausgewählten Fotos, die nicht danach irgendwann eine Farbmarkierung bekommen haben, schaue ich gnadenlos auf Verbleib durch.

 

[brontes]

Nun hat mein Katalog noch deutlich 1-stellige GB bei ca. 130.000 Fotos und exzessivem Entrauschen in den letzten Jahren.

Naja, kann ich nicht bestätigen. Beim Test der letzten rund 1400 Entrauschungen mit LrC 15.0 ist mein Katalog um rund 14 GB gewachsen. Das wären dann bei ca. 130.000 Fotos eine Kataloggröße von 1,3 TB.