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.