[Digikam-devel] [digikam] [Bug 309058] Database can't be synchronized with XMP sidecars

[Elle Stone]

https://bugs.kde.org/show_bug.cgi?id=309058

--- Comment #44 from Elle Stone <ellestone at ninedegreesbelow.com> ---
Here are my digiKam settings:
Under Reading and Writing Metadata:
     "Read from sidecar files" is checked.
     "Write to sidecar files" is checked. "Write to XMP sidecar only" is also
checked.
     "If possible write Metadata to RAW files (experimental)" is NOT checked.
Under Rotation:
     "Rotate by only setting a flag" is selected. 
     "Write flag to metadata if possible" is also checked. 

With the above metadata settings, testing shows that:
     * Syncing from the database to the image writes new/modified metadata to
the XMP file, and completely replaces with old tag trees with new tag trees.
     * Rotating an image sets a flag in the database, and syncing from the
database to the image writes the flag to the XMP file.
     * The XMP tag trees and rotation flags survive deleting the database and
making a new one.

Regarding syncing:
     * Syncing from database to image: I closed digiKam and modified an XMP
file with a text editor, changing one item in a "tag branch". Then I opened
digiKam and synced from the database to the "image" (actually XMP file). The
externally modified tag branches were rewritten by the digiKam database tag
branches. This is exactly what I want to happen. I don't intentionally use
other software to add or modify XMP tags, but sometimes other software tries to
write tags anyway.
     * Synching from image to database: I closed digiKam and modified an XMP
file using a text editor, again changing one item in a tag "branch". Then I
opened digiKam and synced from the "image" to the database. digiKam picked up
the new "tag branch", but the original "tag branch" was still there. This is
exactly what I want to happen: If I ever accidentally sync from the image to
the database, I don't want syncing to remove or modify tags that I've added
using digiKam. I didn't  test syncing from image to database very carefully,
and I'm not sure how this behavior would cohere with workflows that depend on
digiKam reading in data written by other software.

All the above seems to work as I'd expect it to, given the metadata settings.
The original problems seem to be fixed. I've only tested with a very small
database of images. Hopefully results will be the same on the real database.
But I think this bug can be closed. If working with the real database reveals
remaining or other issues, maybe open a new bug report?

(In reply to Veaceslav Munteanu from comment #43)
> Everything that works with normal image metadata should work with sidecars.
> I'm not a fan of them, tried them only once.

Many people never write metadata to their original image files, because there's
always an element of risk.

-- 
You are receiving this mail because:
You are the assignee for the bug.