[Digikam-users] about "synchronizing XMP sidecars and the digiKam database"

[Jean-François Rabasse]

Hello,

I'd like to be back to that interesting issue that was longly
discussed this past week, metadata synchronisation. I found the
discussion interesting because it clearly shows that problems exists
and that a number of users feel concerned. But the final state seems
now to be : « So what ? »

Maybe it could be useful to try doing a bit of synthesis and extract
a few guidelines and wish-lists ?

As for me, I may be wrong but..., I see three points, with only one
of major importance.


1. Sidecar files vs. metadata into image files.

My personal feeling is that it's an off-topic issue. Metadata
import/export complies to standards, XMP/RDF, and the data stream is
the same. Be it into a separate sidecar file, or transported in the
image file is just a matter of taste and trust. Some users are
reluctant to write into images, because of experimental writing to
RAW files, or because they use other software that corrupts
metadata. Whatever, it's personal taste and option.

Perhaps the only expected thing from Digikam would be to be sure
that reading and writing works well in both case, from/to image,
from/to sidecar. For images files, it does work well, for sidecar
files I don't know. My version (Digikam 2.6.0) writes correct
sidecar files but doesn't read. Maybe this has been fixed in the
meantime and so, the issue is over.


2. Tags reloading into the DK database.

Hum, I feel this is THE major problem. It has been discussed in
details. There are two possible behaviours, merge tags to already
existing tags, or read and replace.
Stating if this should be an option or not isn't that easy without
users usage statistics and use cases.

Recently, Gilles said :

On Tue, 19 Feb 2013, Gilles Caulier wrote:

> The goal is to check which option must be turned on by default to
> satisfy a lots of users by default.

Sounds really wise !
My personal feeling (react if you think I'm wrong) is that the most
natural default is « replace » mode, not « merge » mode.

The rationale could be that this is the expected behaviour for all
users that manage their images with Digikam and only Digikam,
(it's a all-in-one software), doing reversible operations.
And it would greatly help users to reorganise their tags
(Marie-Noëlle and certainly many other users) and also having a
« mirror » backup of metadata, in images or sidecar files,
before re-installing a new version.

I think merging interests mostly users that deal with different
programs (I don't know if it's 5% of us or 95%), but these users
have, per se, different metadata management tools. And merging is
already possible to do outside Digikam
(exiftool -xmp-digikam:tagslist+=My/New/Tag... images or sidecars...).
And then Digikam only requires a simple re-read in replace mode,
et voilà, post-merge synchronisation is done.

** So, I vote for a « replace tags upon reading » mode as a default.
(And the fix is easy, this has been discussed, and will probably fix
80% of problems.)


3. Control over metadata export

This is a great and difficult problem. Digikam tends to export
metadata in many many places, and sometimes in a questionable way.
Cf.

On Thu, 21 Feb 2013, Elle Stone wrote:

> The digiKam/exiv2 changes I had in mind were changes in how the
> actual strings are written, and where they are written to.
> At present (or at least last I checked, as noted in the article
> you mentioned) digiKam writes some of the strings ("title",
> for example) to technically incorrect places.

I totally agree. I've already had data destroyed by Digikam,
when updating a title for some JPEG images that already contained a
JPEG comment plus a different Exif:UserComment. And all that
vanished after Digikam updating Dublin Core title and overwriting my
existing data. (Considering that dc:title and exif:usercomment and
jpeg:comment are synonyms is a semantic error ! )

And that's one of the reasons I've stopped allowing DK to write into
my images. Only sidecars are allowed as it's easy, afterwards,
to extract what is wanted from sidecars and to put into images and
where.

But should this require urgent fixes ? I'm not sure. As long as
users have the possibility to export from database to sidecars,
then to choose exactly what should be into images, it's not a real
problem. Let Digikam work in a symmetrical way between read/write,
cf. point 2, and process apart metadata exchange issues.

Maybe, what could be suggested for future releases is to do more
careful export, something like :
- write image title to XMP DC title
- IF exif:usercomment is empty/unset, write title too, ELSE left
unchanged.
- IF JPEG comment is empty/unset, write title too, ELSE left
unchanged. But this is detail, the workaround is already on the
shelf, « don't touch my images » , I'll do it myself : -)


Regards,
Jean-François


PS: a last comment, relating to what Gilles said :

On Tue, 19 Feb 2013, Gilles Caulier wrote:

> Secondary, the big question to know is how main Photo management
> program work with tags workflow in metadata. When i said main
> applications, i said real pro photograph application, as Aperture,
> NX, LR, etc...

Big question, yes. Tags trees are special metadata in the way that
it has been forgotten in standard schemes, and it is so useful that
every software team implements them, Digikam, Adobe Lightroom,
Microsoft Photo...

My first bet is that in the future next years, this will probably be
added to a standard schema (Dublin Core seems to be a good candidate
to host both dc:subject and dc:tagslist (plus support for a
controlled or managed vocabulary as already suggested for
dc:subject).)

My second bet is that the standard syntax (components separator in
tagstree, a '/' as in Digikam, a '|' as in Lightroom) will probably
be Adobe syntax. The reason is that, on the earth and since the
Neanderthal era, it's always the heavier that wins. : -)

So, all images related software should probably be prepared to do a 
migration, one day or the other, and rewrite their tags to the now
standard place, under a standard syntax. We just have to wait...