Lightroom: DNG-Dateien nicht verändern?

[Skalex]

Hallo miteinander!

Ich bin neuer Lightroom-Benutzer und bevor ich alle meine Fotos importiere, stellt sich mir eine Frage, die mir vielleicht jemand von euch beantworten kann:
Als Pentaxianer nehme ich direkt DNG-Dateien mit meiner Kamera auf (statt dem Pentax-eigenen Rohformat). Nun sind mir diese Originaldateien sozusagen heilig und ich möchte nicht, dass z.B. Lightroom diese verändert, und sei es nur, um aktualisierte Metainformationen hineinzuschreiben oder gar das Vorschaubild auszutauschen. Am liebsten wäre mir eine Lösung wie bei den proprietären Formaten auch, dass nämlich eine XMP-Sidecar-Datei geschrieben wird. Kann ich Lightroom irgendwie dazu bewegen meine Originale nicht anzutasten?

Ich habe schon die Hilfe, Google und die Forensuche bemüht und konnte nicht viel Brauchbares in dieser Hinsicht finden. Ich habe in den Einstellungen "Änderungen automatisch in XMP speichern" ausgeschaltet, aber wenn ich denn irgendwann mal aus Versehen Strg+S drücke oder den entsprechenden Menüpunkt anwähle, wird das Original doch verändert. Die Dateien mit dem Schreibschutz-Attribut zu versehen hilft auch nur bedingt, denn während das normale Schreiben der Metadaten damit zwar unterbunden wird (in Lightroom erscheint ein Ausrufezeichen über dem Miniaturbild um einen Konflikt anzuzeigen), ist es immer noch möglich "DNG-Vorschau und Metadaten aktualisieren" auszuwählen, um das Original zu verändern. Und da ich mich mit dem Programm noch nicht gut auskenne, gibt es vielleicht noch andere mir unbekannte Möglichkeiten, die schreibend in mein Original eingreifen.

Grüße,
Stefan

 

[blende7]

Einfachste Lösung wäre PEF Dateien aufzunehmen.
Da wird nix reingeschrieben.

Andererseits, so schlimm ist es ja nicht, wenn da was reingeschrieben wird. Du kannst jederzeit auf "as shot" oder so zurückschalten. Kenne LR nicht, aber in ACR muss man einfach auf "Camera RAW Defaults" gehen.

 

[Skalex]

Danke für die Antwort. Klar, PEF aufnehmen ist das einfachste. Aber ich habe zum einen schon viele existierende DNG-Dateien und zum anderen würde ich gerne bei DNG bleiben wegen Zukunftssicherheit und so. Wobei ich jetzt keine Diskussion zum "richtigen" Rohformat anstoßen will, davon gibt's hier schon genug .

Ich kenne ACR nicht so richtig, aber wenn "as shot" ungefähr dem "Zurücksetzen" von LR entspricht, so setzt das die Entwicklungseinstellungen zurück. Aber das will ich ja nicht. Ich möchte, dass meine Originaldatei nie und unter keinen Umständen schreibend bearbeitet wird und alle Entwicklungseinstellungen entweder nur im Katalog oder in einer Sidecar-Datei gespeichert werden.

Warum will ich nicht in die Originaldatei schreiben? Weil ich der Meinung bin, dass da immer was schiefgehen kann, weil Programme immer irgendwo Fehler aufweisen und man sich nie sicher sein kann, ob nicht irgendetwas überschrieben wird. Zuguterletzt möchte ich sozusagen als Referenz das Vorschaubild, das meine Kamera in die DNG-Datei schreibt, erhalten und nicht durch eine LR-generierte Vorschau ersetzen.

Wie es ausschaut, werde ich wohl schon vor dem LR-Import Backups meiner Originaldateien anlegen, dann kann ich für den Fall, dass ich doch mal aus Versehen den falschen Menüpunkt anwähle, diese wieder zurückspielen. Etwas umständlich, aber ich reagiere nunmal allergisch auf Veränderungen meiner Originale.

 

[JürgenR]

Das wird ja allgemein als Vorteil angesehen, daß man keine zusätzlichen Dateien benötigt, wie bei den normalen RAW-Formaten. Gut, du siehst es eben anders.

Dafür gibt es keine Möglichkeiten, außer den bereits von dir beschriebenen Methoden: Schreibschutz und aufpassen. Den Menüpunkt erreicht man ja nicht unbedingt so versehentlich. Das dürfte ja nicht das große Problem darstellen.
Zusätzlich könntest du in der TranslatedStrings.txt den Shortcut CTRL-S suchen und dort deaktivieren. Dann ist zumindest diese Möglichkeit mal weg.

Warum es allerdings möglich ist, über den Menüpunkt Daten zu ändern, trotz Schreibschutz, ist mir schleierhaft. Normalerweise sollte das gar nicht möglich sein, außer die Routine hebt kurzfristig den Schreibschutz auf.

Jürgen

 

[Skalex]

Vielen Dank Jürgen! Den Vorteil von nur einer Datei sehe ich auch, aber das ist für mich in der Tat eher zweitrangig. Immerhin weiß ich jetzt, dass das, was ich möchte, nicht so ohne Klimmzüge geht.

Du hast schon Recht, die Menüpunkte klickt man selten mal aus Versehen an. Ich hatte auch hauptsächlich Bedenken wegen Strg+S. Nach deinem Tipp habe ich in der TranslatedStrings.txt den entsprechenden Shortcut herausgelöscht, jedoch scheint er immer noch zu funktionieren... da muss ich wohl noch etwas rumprobieren. Eigentlich schade, dass nicht vorgesehen ist, die Shortcuts zu verändern.

Dass schreibgeschützte Dateien verändert werden können, hat mich auch etwas überrascht. Das scheint jedoch nicht beim normalen Schreiben der Metadaten zu geschehen, sondern nur, wenn man explizit "DNG-Vorschau und Metadaten aktualisieren" auswählt. Im Prinzip muss ich also nur meine Dateien schreibschützen und darauf achten nicht auf genau diesen Menüpunkt zu klicken. Ich denke das ist ein ganz akzeptabler Workaround.

 

[yamiro]

Wie es ausschaut, werde ich wohl schon vor dem LR-Import Backups meiner Originaldateien anlegen...

Warum nicht komfortablerweise _während_ des Importes? Das Backups ist eine Option des Importdialoges.

 

[Gast_99693]

Warum es allerdings möglich ist, über den Menüpunkt Daten zu ändern, trotz Schreibschutz, ist mir schleierhaft. Normalerweise sollte das gar nicht möglich sein, außer die Routine hebt kurzfristig den Schreibschutz auf.

das ist tatsächlich so - gerade eben ausprobiert

Schreiben der Metadaten (Ctrl-S) lässt ein schreibgeschütztes DNG so wie es ist. "DNG-Vorschau und Metadaten aktualisieren" hebt den Schreibschutz auf und überschreibt die DNG-Datei! Und belässt sich auch noch im Zustand "nicht schreibgeschützt". So zumindest beobachtet unter Windows XP 32Bit SP3 mit LR 3.3 RC.

Naja gut, damit kann man leben, denn dazu muss man erstmal ins Menü, denn dieser Menüpunkt hat auch kein Tastaturkürzel.

@Skalex: Du bist aber nicht der einzige, der das so sieht. Hier z.B. eine (kurze) Diskussion dazu im Adobe-Forum http://forums.adobe.com/thread/745973.

Ich persönlich bleibe auch erstmal bei proprietären RAWs, weil ein XMP-Backup der Entwicklungseinstellungen außerhalb des LR-Kataloges haben will und mich das mit der dafür notwendigen DNG-Änderung ziemlich nervt beim Backup. Die separaten Filialdateien sind da deutlich schneller und man kann sich zur Prüfung von Backup-Platten ein für alle Mal gültige Prüfsummen für die RAWs generieren - bei DNG geht das dann leider nicht mehr, es sei denn, man verzichtet dauerhaft auf das Speichern der XMPs in den DNGs.

Ich bin aber auch am überlegen, ob ich wirklich das Sicherheitsnetz der XMP-Daten brauche - denn historische Katalogbackups sollte man sowieso haben (kann ja LR von sich aus machen), d.h. die Gefahr, alle Katalogdaten durch "Zerschießen" der Katalogdatei zu verlieren ist praktisch nicht vorhanden (höchstens die der letzten Tage/Wochen, je nachdem wie man LR eingestellt hat). Und gegen DNG an sich habe ich auch prinzipiell nichts (mehr). Und sollte ich irgendwann von LR auf etwas anderes umsteigen (müssen), dann muss man sich sowieso Gedanken über eine entsprechende Migrationsstrategie machen (inkl. Übertragung der XMPs etc.).

Das einzige, wo ich momentan am grübeln bin, ist eine Spezialanwendung: Für Timelapse-Aufnahmen will ich mir noch ein Tool basteln, das in einer RAW-Sequenz bestimmte Entwicklungseinstellungen kontinuierlich verändert (z.B. Zoom/Pan direkt in der LR-Entwicklung), was über XMP funktioniert, und da wären die Filialdateien natürlich deutlich schneller (vermute ich). Andererseits könnte man dafür auch DNG verwenden und fürs Backup diese nicht automatisch immer wieder sichern, sondern nur 1x nach dem Import, würde auch gehen. Wie gesagt, bin da noch am grübeln...

Noch was:

Warum will ich nicht in die Originaldatei schreiben? Weil ich der Meinung bin, dass da immer was schiefgehen kann, weil Programme immer irgendwo Fehler aufweisen

Nicht nur Programme. Auch defektes RAM, SATA/USB-Kontroller etc. können unbemerkt Daten verfälschen. Mit RAM ist mir das schon passiert - ironischerweise waren die Daten des Backups zerstört, was ich nur durch ein nachträgliches Verfify mit Prüfsummen gemerkt hatte.

 

[Gast_99693]

Zusätzlich könntest du in der TranslatedStrings.txt den Shortcut CTRL-S suchen und dort deaktivieren.

Nach deinem Tipp habe ich in der TranslatedStrings.txt den entsprechenden Shortcut herausgelöscht, jedoch scheint er immer noch zu funktionieren...

Vorsicht, böse Falle: Das hier ist die falsche Stelle:

"$$$/AgLibrary/Help/Shortcuts/SaveMetadata=Metadaten in Datei speichern"
"$$$/AgLibrary/Help/Shortcuts/SaveMetadataKey=Befehl + S"

Wenn man da den Key löscht, löscht man nur den Hilfetext in der Tastaturkürzel-Übersicht des Bibliotheksmodules!

Hier ist die richtige Stelle:

"$$$/AgLibrary/XMP/ExportXMPToFile=Met&adaten in Datei speichern"
"$$$/AgLibrary/XMP/ExportXMPToFile/Key=[COLOR="Red"]Cmd+s[/COLOR]"

Das rot markierte Löschen, dann ist der Shortcut weg. Zur Kontrolle: Im Menü darf der Shortcut dann auch nicht mehr angegeben sein. Man kann auch noch das "&" aus dem Menütext löschen, dann kann man den Menüeintrag auch nicht mehr über die Tastatur mit "a" ansteuern.

 

[JürgenR]

Nach deinem Tipp habe ich in der TranslatedStrings.txt den entsprechenden Shortcut herausgelöscht, jedoch scheint er immer noch zu funktionieren... da muss ich wohl noch etwas rumprobieren. Eigentlich schade, dass nicht vorgesehen ist, die Shortcuts zu verändern.

Hast du die Zeile herausgelöscht oder nur verändert? Versuch nur mal den Teil hinter dem Gleichheitszeichen zu löschen?
Wenn die Zeile komplett gelöscht ist, wird die Originalbelegung direkt in der Programmierung festgelegt. Im englischen ist der Shortcut nämlich gleich.
Nur wenn es eine Änderung in der Translatedstrings.txt gibt, wird das stattdessen verwendet.
Wenn nur der Teil hinten fehlt, wo die eigentlich Taste festgelegt ist, könnte es zumindest funktionieren. Habe ich aber selbst noch nie ausprobiert.

Ich kenne das Prinzip noch daher, als ich mich irgendwann mal mit der Programmierung der Webgalerien beschäftigt hatte. Die sind ebenfalls in LUA geschrieben und dort funktioniert das exakt gleich.
Nach diesem Prinzip lassen sich auch fast alle Shortcuts ändern.

Da hatte ich mich im ersten Post wohl etwas knapp ausgedrückt.

Jürgen

 

[Gast_99693]

Wenn die Zeile komplett gelöscht ist, wird die Originalbelegung direkt in der Programmierung festgelegt. Im englischen ist der Shortcut nämlich gleich.
Nur wenn es eine Änderung in der Translatedstrings.txt gibt, wird das stattdessen verwendet.

Das war mir neu, Danke für den Hinweis!

Wenn nur der Teil hinten fehlt, wo die eigentlich Taste festgelegt ist, könnte es zumindest funktionieren.

Tut es ... siehe oben
Ich hatte mehr oder weniger "instinktiv" nur das "Cmd+s" gelöscht und nicht die ganze Zeile.

Es gibt übrigens jede Menge Einträge, die auf ".../Key=" enden. Das scheint also auch kein Zufall zu sein, sondern wirklich offiziell "leer = kein Shortcut" zu bedeuten.

Ach ja, noch ein ganz anderer Hinweis: Auf jeden Fall einen Editor benutzen, der Unicode/UTF8-fähig ist und das BOM (Byte Order Mark) der Datei richtig lesen und schreiben kann! Bei Windows sollte man da mit notepad.exe auf der sicheren Seite sein.

 

[JürgenR]

Tut es ... siehe oben
Ich hatte mehr oder weniger "instinktiv" nur das "Cmd+s" gelöscht und nicht die ganze Zeile.

Die Beiträge hatten sich etwas überschnitten.

Jürgen

 

[JürgenR]

Das war mir neu, Danke für den Hinweis!

Aus dem Grund gibt es ja auch keine Translatedstrings.txt für die englische Version. Da ist dann die Sprache/Tastenbelegung direkt im Quellcode enthalten. Man kann über eine eigene Textdatei aber trotzdem z.B. Tasten ändern, wenn man die im richtigen Verzeichnis ablegt.

Beispiele siehst du, wenn du mal in den Quellcode einer Webgalerie reinschaust. Dort findet das ebenfalls Anwendung.

Jürgen

 

[Skalex]

Danke, ihr habt mir beide sehr weitergeholfen! Das Tastenkürzel ist jetzt weg . Ich benutze übrigens Notepad++, das Unicode auch ordentlich auf die Reihe kriegt.

Im übrigen ist mir noch eine weitere Methode eingefallen, mit der man die Originale vor Veränderung schützen könnte, wobei der Versuch noch aussteht: Man kann die Dateiberechtigungen so setzen, dass normale Benutzer mit eingeschränkten Rechten nicht mehr schreibend auf sie zugreifen dürfen. Da Lightroom im selben Kontext läuft, dürfte es folglich die Dateien nicht mehr anrühren. Nachteil ist, dass man neue Bilder dann entweder als Admin (bzw. als Nutzer mit entsprechenden Rechten) von der Speicherkarte holen bzw. von diesen Bildern nachträglich die Benutzerrechte einschränken muss. Hört sich auch nicht unbedingt praktisch an.

[Edit] Ich habe diese Methode eben ausprobiert und sie funktioniert wie erwartet. Wie gehabt gibt es ein kleines Ausrufezeichen, wenn man versucht die Metadaten in die Datei zu schreiben. Versucht man die Vorschau zu aktualisieren, so wird oben im Fenster "DNG-Vorschau und Metadaten werden aktualisiert" angezeigt, was erst durch Klick auf das kleine "x" daneben abgebrochen wird. [/Edit]

@starscapefan: Hmm, die Checksummenprüfung war bis jetzt noch nicht Teil meines Backup-Plans, aber das sollte ich vielleicht ändern, vor allem wenn so etwas fieses wie ein defekter RAM-Riegel einem die Daten verändert...

@yamiro: Dass Lightroom schon während des Imports Backups anlegen kann, habe ich bereits gesehen. Allerdings schreibe ich meine Sicherungen (momentan noch) auf DVD, was ich mit Lightroom wohl eher nicht hinbekomme.

 

[Gast_99693]

Versucht man die Vorschau zu aktualisieren, so wird oben im Fenster "DNG-Vorschau und Metadaten werden aktualisiert" angezeigt, was erst durch Klick auf das kleine "x" daneben abgebrochen wird.

Tolle Fehlerbehandlung ... *kopfschüttel*

Ist mir aber auch schonmal woanders aufgefallen... und zwar im Druckmodul: Wenn man versucht, ein normalgroßes Bild (so 10MP) mit der manueller PPI-Einstellung auf Maximum in eine Datei zu drucken (ok, nicht praxisrelevant), scheint das Resultat so groß zu werden, dass es auf irgendeine LR-interne Beschränkung läuft (Bildgröße oder Speicher, was auch immer). Auf jeden Fall erscheint dann auch "Drucken wird vorbereitet...", aber es tut sich nichts mehr, keine CPU-Last, keine Plattenaktivität, nichts. Abbrechen geht aber noch.

Ich wette, da werden intern irgendwo Exceptions einfach so weggefangen, ohne sie dem Benutzer anzuzeigen und ohne den Thread zu benachrichtigen, der auf das Ende der Aktion wartet. Eigentlich ein sehr "beliebter" Programmierfehler

Hmmm.... ich sollte mal wieder einen weiteren netten Bugreport an Adobe schreiben ... das wäre dann glaube ich mein sechzehnter

P.S. Völlig vergessen: Danke für die Idee mit den Berechtigungen. Da kann man sich doch bestimmt ein Batchfile basteln, das die Berechtigungen für alle DNGs in einem Verzeichnis ändert, oder? Viel umständlicher als alle auf Read-Only zu setzen ist es dann ja auch nicht mehr...

 

[Skalex]

Tolle Fehlerbehandlung ... *kopfschüttel*

Hmmm.... ich sollte mal wieder einen weiteren netten Bugreport an Adobe schreiben ... das wäre dann glaube ich mein sechzehnter

Hehe, das untermauert nur mein Misstrauen in Programme, die Originaldateien verändern wollen .

Da kann man sich doch bestimmt ein Batchfile basteln, das die Berechtigungen für alle DNGs in einem Verzeichnis ändert, oder? Viel umständlicher als alle auf Read-Only zu setzen ist es dann ja auch nicht mehr...

So viele Batch-Files habe ich unter Windows noch nicht zusammengebastelt, aber möglich sollte das bestimmt sein. Jetzt wäre es natürlich noch sehr elegant, wenn man das Skript automatisch von LR nach einer Importaktion ausführen lassen könnte, dann muss man sich auch nicht mehr selbst darum kümmern. Aber so etwas ist eher nicht vorgesehen, oder? Vielleicht lässt sich ein kleines Plugin entwickeln...

Aber bevor ich in die Pluginentwicklung für LR einsteige sollte ich es erstmal richtig anfangen zu benutzen - dafür habe ich es schließlich gekauft, nicht zum dran Rumbasteln .