[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: [hidden email]
           Summary: XMP metadata interoperability problem and
                    inconsistency
    Classification: Unclassified
                OS: Linux
          Reporter: [hidden email]
          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.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

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

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #1 from Gilles Caulier <[hidden email]> ---
I recommand to test with last digikam 2.7.0 and last libkexiv2 from kdegraphics
component where we have fixed some code about xmp management

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

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

--- Comment #2 from Marcel Wiesweg <[hidden email]> ---
Sorry, the dc properties are all lowercase. (in contrast, tiff: properties
start uppercase). Please refer to the XMP specification.
The XMP specification does not state anything about case sensitivity, so I
agree with you that XMP is case sensitive as XML is. Which means the sample
image contains an entry which is not defined in the dc namespace.

Which software is writing dc.Title?

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Jean-François Rabasse]

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

--- Comment #3 from Jean-François Rabasse <[hidden email]> ---
(In reply to comment #2)
> Sorry, the dc properties are all lowercase. (in contrast, tiff: properties
> start uppercase). Please refer to the XMP specification.
> The XMP specification does not state anything about case sensitivity, so I
> agree with you that XMP is case sensitive as XML is. Which means the sample
> image contains an entry which is not defined in the dc namespace.
>
> Which software is writing dc.Title?

Hello Marcel,

Thanks for feedback. I've also investigated and it appears the problem comes
from a historical DCMI inconsistency.
As they say themselves, (cf. http://dublincore.org/documents/naming-policy/)
"In 1998, the Dublin Core element set was published using Names (at the time
called Labels) which had a leading uppercase character, e.g. Title and Creator
[RFC2413]. In October 2000, the DCMI Advisory Committee decided to change the
Names of elements to lowercase in order to bring DCMI practice into line with
conventions widely (though not universally) followed in existing Dublin Core
applications and in the XML and RDF/XML communities more generally.

Unfortunately, this decision was propagated throughout DCMI documentation only
after some delay [DC-ELEMENTS]. In the meantime, the Dublin Core Metadata
Element Set had progressed through formal standardization channels for
recognition first as NISO Z39.85-2001 and CEN Workshop Agreement CWA 13874,
then as ISO 15836 -- with element Names starting in uppercase [ISO15836]."

So, they started with capitalized elements names, then changed their mind to
all lowercase at a moment the ISO standard was already on its way. Too bad.

I suggest to close this issue, as it is clearly not an applications issue. I
don't know, due to this formal inconsistency, how many images on the earth may
embed a xmp.dc.Title instead of xmp.dc.title.
As DCMP suggest (IMHO in a somewhat casual way) "In practice, this suggests
that applications are well advised to normalize case when parsing terms for
identity comparisons", I've fixed my immediate problem, in my reading program,
by checking both syntaxes.
Something like :
 - get xmp.dc.title
 - if non existent or empty, get xmp.dc.Title
This solves my problem and I can live with, that way :)

Regards
Jean-François

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

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

Marcel Wiesweg <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WORKSFORME

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

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

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Version Fixed In|                            |3.0.0

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel