[Digikam-devel] [Bug 304077] New: XMP metadata interoperability problem and inconsistency

[Jean-François Rabasse]

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

            Bug ID: 304077
          Severity: minor
           Version: 2.2.0
          Priority: NOR
          Assignee: digikam-devel at kde.org
           Summary: XMP metadata interoperability problem and
                    inconsistency
    Classification: Unclassified
                OS: Linux
          Reporter: jean-francois.rabasse at wanadoo.fr
          Hardware: openSUSE RPMs
            Status: UNCONFIRMED
         Component: Metadata
           Product: digikam

Problem with the way Digikam reads/writes XMP metadata and with potential
interoperability with other applications.

1. A sample image (reduced size version) is available here :
   http://e-artefact.eu/scratch/DSC_1881.JPG
This image contains a title in the Dublin Core Title property (XMP section of
the file)
This title is readable by command line tools,
   exiftool -g DSC_1881.JPG
   ---- XMP ----
   Title  : Rue des Francs Bourgeois
or
  exiv2 -p x DSC_1881.JPG
  Xmp.dc.Title        XmpText    24        Rue des Francs Bourgeois

2. This image is imported into a Digikam folder (and also « Reread Metadata
>From Image »)
Digikam correctly displays the title in the XMP Metadata infos, folder on the
right, but doesn't seem to use the image title on the album thumbnails view, as
could be expected.
See screenshot 1 here : http://e-artefact.eu/scratch/Screenshot-1.jpg

3. A copy of this image is done, DSC_1881_1.JPG
   (Available here : http://e-artefact.eu/scratch/DSC_1881_1.JPG )
This new image gets a new title, « Digikam title », edited from the GUI
(Caption/Tags folder),
plus operations « Write Metadata to Image », « Reread Metadata From Image ».

The strange thing :
- Digikam correctly displays the new title in the album thumbnails view, as
expected
- Digikam still displays the original title in the XMP Metadata folder
See screenshot 2 : http://e-artefact.eu/scratch/Screenshot-2.jpg


Investigations :
After Digikam has written an edited image title to the image file, the XMP
section contains two Dublin Core Title properties. The original one named
dc.Title is still present, and the Digikam written one, named dc.title with a
lowercase 't'.

This doubled titling can be seen with other applications, e.g. Gwenview shows
two titles,
(See screenshot 3 http://e-artefact.eu/scratch/Screenshot-3.jpg )
and exiv2 too :
  exiv2 -p x DSC_1881_1.JPG
  Xmp.dc.Title                   XmpText    24  Rue des Francs Bourgeois
  Xmp.dc.title                    LangAlt        1  lang="x-default" Digikam
title
  Xmp.xmp.CreatorTool      XmpText    13  digiKam-2.2.0
  Xmp.tiff.Software            XmpText    13  digiKam-2.2.0

NB: the Gwenview metadata display, as on screenshot 3, is a bit confusing
because properties labels seem to be reformated with capitalized names. The
exiv2 output, however, shows clearly the case difference.


Conclusions and questions :
1. Seems that Digikam doesn't adhere to the case conventions in DC properties
names, where the Title has an uppercase 'T'. As a XMP section is an XML
structure and thus is case sensitive, this breaks interoperability with other
applications, reading or writing title.

2. But if Digikam writes dc.title when writing metadata to image, why does it
look for dc.title to get an image title for the album thumbnails view, but
reads dc.Title to display metadata information (Screenshot 2)
I first thought the original title was kept in the Database and not updated
across title edition, but it's not the case. Digikam database contains only the
new edited title :
  sqlite3  digikam4.db
  > SELECT IM.name, IC.comment FROM images AS IM, imagecomments AS IC 
     WHERE IM.id = IC.imageid and IM.name LIKE 'DSC_1881%';
  > DSC_1881_1.JPG | Digikam title
Nothing at all about the initial title, so displayed text (Screenshot 2) does
come from the image metadata section.

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