Erstellung von XMP-Dateien bei JPGs unterbinden

155 views
Skip to first unread message

Robert Steichele

unread,
Nov 25, 2015, 2:46:49 AM11/25/15
to JPhotoTagger Benutzer
Hallo,

ist es möglich beim indizieren der definierten Verzeichnisse, das Erstellen der XMP-Dateien bei JPGS zu unterbinden?

Elmar Baumann

unread,
Nov 25, 2015, 1:10:36 PM11/25/15
to jphototagg...@googlegroups.com
Am 25.11.2015 um 08:46 schrieb Robert Steichele:
> ist es möglich beim indizieren der definierten Verzeichnisse, das
> Erstellen der XMP-Dateien bei JPGS zu unterbinden?

Hallo Robert,

die XMP-Dateien sind die Basis von JPhotoTagger. Es lassen sich Dateien
ausschließen, z.B. dass keine JPEGs eingelesen werden. Diese erscheinen
dann auch nicht in der Anzeige. Wieso sollen für JPEG-Dateien keine
XMP-Dateien erstellt werden? Vielleicht hilft noch folgendes: Bearbeiten
> Einstellungen > 6. Sonstiges > Verschiedenes: Lange XMP
Filialdateinamen nutzen. Dann heißen die XMP-Dateien Bild.jpg.xmp sowie
Bild.raw.xmp und es können zwei Bilder den gleichen Namen mit
verschiedener Endung haben. Vorher sollten dann per Batch existierende
XMP-Filialdateien umbenannt werden, da diese sonst nicht mehr "gesehen"
werden.

Grüße,
Elmar
--
http://www.elmar-baumann.de/fotografie/

Robert Steichele

unread,
Nov 26, 2015, 1:46:53 AM11/26/15
to JPhotoTagger Benutzer
Hallo Elmar,

bei mir läuft das so, ich verschlagworte meine Raws mit JPT, gehe dann in C1 und lasse dort beim Exportieren die Schlagworte Metadaten etc. direkt in die JPGs schreiben. JPT möchte ich dann noch benutzen um später nach den Bildern zu suchen. Der Übersicht halber und auch wegen der Anzahl der Dateien auf dem Laufwerk wäre es für mich toll, wenn JPT diese JPGs zwar indiziert, aber keine zugehörigen XMP-Dateien erstellt. Die Metadaten und Keywords sollen bei diesen JPGs auch nicht mehr verändert werden.

Viele Grüße
Robert

Elmar Baumann

unread,
Nov 26, 2015, 12:57:45 PM11/26/15
to jphototagg...@googlegroups.com
Hallo Robert,

JPhotoTagger benutzt die Datenbank lediglich für die Suche. Der
eigentliche Speicherort für die Metadaten sind die XMP-Filialdateien.

Das andere Konzept ist häufiger anzutreffen: Bilder sind erst in eine
Datenbank zu "importieren" und dort sind dann alle relevanten Metadaten.
Ist die Datenbank defekt, geht nichts mehr.

Es lassen sich dann z.B. bei Lightroom die Daten der Datenbank wieder in
XMP-Filialdateien zurückschreiben. Dann kann man so im Falle eines
Datenbankcrashes die Metadaten wieder in die Datenbank einlesen lassen.

Das sind jedoch zwei Arbeitsschritte: 1. Bilder in die Datenbank
importieren. 2. XMP-Dateien schreiben lassen.

Vergisst man 2., sind mit einem Datenbankcrash alle Metadaten verloren.
In Lightroom lässt sich 2. automatisieren, aber davon wird abgeraten, da
dies die Arbeit deutlich verlangsamen kann.

Kurz: Mit JPhototTagger sollen diese zwei Schritte entfallen und
insbesondere ein Datenbankcrash kein Problem sein. Das wiederum hat
seine spezifischen Nachteile: Es werden alle Bilder angezeigt - außer
man definiert Ausschlusspattern, was umständlich sein kann - und es
werden zusätzliche Dateien erzeugt, je Bild eine. Dafür hat man
Datensicherheit und die Metadaten lassen sich notfalls sogar auf der
Kommandozeile lesen ("more Datei.xmp") oder besser in einem Text- oder
XML-Editor.

Man könnte auch direkt in die JPEGs oder TIFFs schreiben statt
Filialdateien anzulegen (bei RAW-Dateien wäre das eher nicht anzuraten).
Das wollte ich nicht, da bei einer Metadatenänderung eine Datensicherung
sehr umfangreich werden kann, z.B. 100 MB pro 16 Bit-TIFF-Datei versus
wenige Kilobyte für eine XMP-Datei.

Letztlich muss jeder selbst entscheiden, was wichtiger ist. Keine gute
Idee ist übrigens, die XMP-Dateien über den Windows-Explorer
auszublenden. Statt einen Filter sauber zu implementieren, setzt dieser
die Datei auf "versteckt" (ändert das Hidden-Datei-Attribut). Das gibt
dann einen Fehler beim Versuch von JPhotoTagger, Änderungen in die Datei
zu schreiben.

Robert Steichele

unread,
Dec 2, 2015, 9:57:48 AM12/2/15
to JPhotoTagger Benutzer
Hallo Elmar,

ich finde JPT gerade deshalb so toll und interessant, da man eben keine explizite Datenbank pflegen muss, sondern sich den Index einfach anhand der Metadaten aufbauen lässt und wenn der mal kaputt geht, lässt man einfach einen neuen generieren. Eigentlich genau das was ich möchte.

Das Feature, welches mir fehlt wäre, dass JPT die XMP-Dateien zu den Bildern (z.B. JPGs) nur erstellt, wenn explizit die Datenim/zum Bild in JPT geändert wurden und ansonsten rein von den eingebetteten Daten lebt.

Grüße
Robert

Elmar Baumann

unread,
Dec 2, 2015, 12:45:33 PM12/2/15
to jphototagg...@googlegroups.com
Am 02.12.2015 um 15:57 schrieb Robert Steichele:
> Das Feature, welches mir fehlt wäre, dass JPT die XMP-Dateien zu den
> Bildern (z.B. JPGs) nur erstellt, wenn explizit die Datenim/zum Bild in
> JPT geändert wurden und ansonsten rein von den eingebetteten Daten lebt.

Hallo Robert,

ich konnte nicht nachvollziehen, dass JPT automatisch eine XMP-Datei
anlegt, ohne dass über "Bearbeiten" etwas eingegeben wurde. Eingebettete
XMP-/IPTC-Daten können durch Befehl ausgelesen werden, dann wird aber
eine XMP-Datei erzeugt. Grundlage der Datenbank sind die XMP-Dateien,
das ist so programmiert. Es wird zwingend eine XMP-Datei erzeugt, bevor
das erste z.B. Stichwort in die Datenbank gelangt. Würde JPT
"zweigleisig fahren", müsste es konsequenterweise auch Bilder
modifizieren, d.h. XMP darin ändern, also beispielsweise wie Lightroom
arbeiten: Für RAW-Dateien XMP-Dateien mit Ausnahme von DNG und für die
anderen Formate in die Datei schreiben. Dass dem nicht so ist, ist
Absicht mit den bereits beschriebenen Vor- und Nachteilen.
Reply all
Reply to author
Forward
0 new messages