[Digikam-devel] [Bug 309058] The digiKam database can't be synchronized with XMP sidecars.

[Elle Stone]

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

--- Comment #7 from Elle Stone <l.elle.stone at gmail.com> ---
On 10/28/12, Marcel Wiesweg <marcel.wiesweg at gmx.de> wrote:
> https://bugs.kde.org/show_bug.cgi?id=309058
>
> --- Comment #6 from Marcel Wiesweg <marcel.wiesweg at gmx.de> ---
> The "More->" actions essentially do the same but are old code, not
> multithreaded, I should remove them or rather replace them with the
> "Image->"
> actions.

Ah. Replacing them with "Image->" would be nice, as the placement is
very convenient.

> Everything honors the settings regarding XMP sidecar reading or writing.

Except that "write only" isn't paired with "read only". Once the
sidecar has been created, digiKam keeps also reading the image
metadata.

> Your observation regarding the orientation is true: Here the Exif value is
> given priority over the corresponding XMP value. This is a bug for your
> scenario.
> In the old days, we had IPTC and Exif; then came XMP, and the question was
> how
> to detect conflicts if only IPTC or Exif was edited by an older program and
> the
> change not updated into XMP.
> With XMP sidecar files, relevant Exif and IPTC fields are copied into
> corresponding XMP fields in the sidecar file. This is a quite different
> situation. I tend to define that if a sidecar exists, sidecar information
> always takes precedence over file information, not only for XMP, but also
> for
> Exif and IPTC. This is done by simple merging.

This implies that if I tell digiKam to read from and write to the XMP
sidecar file, digiKam writes ONLY to the XMP but reads from BOTH the
image file and the XMP file. Which means any time a user enters XMP
data in the sidecar file, if there is a conflict between an XMP tag
and other tags, the XMP tag gets overidden by non-XMP data in the
image file. Would it be possible to let XMP always take priority over
IPTC and Exif?

Obviously digiKam has to read the image file in order to create the
XMP sidecar in the first place, assuming no other application has
already created an XMP file. My assumption was that once the XMP file
is created, digiKam would read ONLY the XMP file. I think my mistaken
assumption makes more sense than what actually happens.

For example: With regards to orientation, there are actually three
(hopefully only three) places in the metadata where the image
orientation can be store - two exif locations: IFD0 and IFD1, and one
xmp location: XMP-tiff. Only XMP-tiff is copied to the XMP file.

A test:
exiftool -a -s -G1 -orientation 070512_102713.*======== 070512_102713.jpg
[IFD0]          Orientation                     : Rotate 90 CW
[IFD1]          Orientation                     : Rotate 270 CW
[XMP-tiff]      Orientation                     : Horizontal (normal)
======== 070512_102713.jpg.xmp
[XMP-tiff]      Orientation                     : Rotate 90 CW

Upon reading the Image metadata (which again, I assumed would only
read the XMP sidecar file, but I was completely wrong), digiKam
chooses IFD1 over IFD0, and chooses IFD0 over XMP-tiff. Then it
rewrites the XMP-tiff tag in the XMP sidecar file to match the IFD1
(or IDF0, if the IDF1 tag is missing, or presumably vice versa) tag in
the image.

Another test:
exiftool -a -s -G1 -orientation 070512_102713.*======== 070512_102713.jpg
[XMP-tiff]      Orientation                     : Horizontal (normal)
======== 070512_102713.jpg.xmp
[XMP-tiff]      Orientation                     : Rotate 90 CW

This time digiKam respects the XMP sidecar tag over the tag in the
image, which is how I would expect it to act.

On the other hand, if I set digiKam up to read and write to the
*image* metadata, instead of to the XMP sidecar file, then before
changing the orientation in the database, digiKam uses the IFD0 tag
over the XMP-tiff tag:

exiftool -a -s -G1 -orientation 070512_102713.jpg
[IFD0]          Orientation                     : Rotate 90 CW
[XMP-tiff]      Orientation                     : Horizontal (normal)

After changing the orientation flag in digiKam, BOTH tags are
rewritten in the image metadata:

exiftool -a -s -G1 -orientation 070512_102713.jpg
[IFD0]          Orientation                     : Rotate 270 CW
[XMP-tiff]      Orientation                     : Rotate 270 CW

But when writing only to the XMP file, digiKam can't rewrite the non-XMP tag.

Regardless of how one dices up the metadata pie between IPTC, XMP, and
EXIF, it seems to me that if the user says "read (only, except that's
not presently an option) and write only to the XMP sidecar, that the
orientation tag (and any other tag) in the XMP sidecar is the tag that
ought to be respected. Let's say I tag 1000 images, and 200 of them
needed to have the orientation tag changed in order to display
properly. If digiKam resets the XMP-tiff tag in the sidecar every time
the image metadata is read, that's a lot of work to have to redo over
and over again.

> The situation is unclear when a tag does not exist in the sidecar, but in
> the
> file.
>Assuming we have "write only to sidecars", removing properties will
> only
> happen in the sidecar. If all no keywords or rating are found the sidecar
> but
> in the file, this can be because
> a) These fields are stored in the file and were not copied to the sidecar.
> They
> are valid.

On the one hand, if digiKam created the sidecar, presumably digiKam
copies all the relevant information that can be copied to XMP. In the
case of IPTC or Exif storing contradictory information, why not let
XMP take priority? XMP is very well established at this point.

> b) These fields were removed, changes applied to the sidecar, but not to
> the
> file. They are invalid.
> Ideas for a clean solution?

The difference in "what happens", between writing to the image and
writing to the XMP sidecar, at least in part and maybe entirely seems
to be that  by definition writing to the sidecar only means the image
metadata is untouched. But digiKam keeps reading non-XMP information,
and then rewrites it as the corresponding XMP tag, which gets
rewritten again the next time the image metadata is read.

The cleanest solution would be to always give precedence to what is in
the XMP file and assume that the user will eventually reconcile the
differences. Otherwise the database and the XMP file can't be kept
synchronized. Presumably any user who says "don't write to the image
file" realizes that the XMP and the database will soon be out of synch
with one another, and either has plans to deal with that situation
later, or really doesn't care what is in the image metadata.

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