[Digikam-users] writing tags to the files

[Jean-François Rabasse]

Hi Johan,

The « Write metadata to image » , or « to selected images » action
isn't sufficient per se.

As peter said :

On 19.09.2012 09:21, Peter Albrecht wrote:

> did you enable
>    "[x] Save image tags as 'Keywords' tags in metadata
> embedded in file"
> 
> To be found under:
>
>    "Settings" -> "Configure digikam..." -> "Metadata" ->
> "Behaviour"

you have also to define explicitly which (meta)data are to be written,
it's not a « write all » feature. The Settings Metadata folder displays
several checkboxes for different data items, Title and description,
and/or Rating, and/or Tagslist, etc.

It's up to you to check/unckeck item by item, what you wish to be
written and what you prefer not to be. If you haven't check Save
image tags, DK will never write them.

Note also that in that same configuration folder, if you set the
Metadata writing mode to « Write to image only » , or « image and
sidecar file » , you won't need any more to activate the « Write
metadata to image » , it will be done each time you modify something,
the title, rating, tags, etc., without manual intervention.



About metadata being read by other applications :

It's not a simple issue because some metadata fields are more or less
standard across applications, and some other are not. To write your
image title and description, DK uses standard XMP fields, in the
Dublin Core namespace, and these could be read by other applications.

As for Dolphin, Peter answered :

> The part of viewing the tags in dolphin belongs to the topic
> "semantic desktop" of KDE. "Nepomuk" is another term related with
> this.
> 
> Official site: http://nepomuk.kde.org/

NB: some images viewers, e.g. Gwenview, are more images oriented and can
display almost all metadata fields. DK tags appear with Gwenview.

However, tagslist as featured in DK have a hierarchical structure and
this is not fully supported in basic standards. So, DK saves the
information into an application dedicated namespace,
<digiKam:TagsList>, but only Digikam is supposed to be able to read
that. To increase the probability some other applications could read
the info, Digikam saves also tagslist information in several other
metadata fields, hierarchicalSubject, Keywords, Subject.
Maybe other...

This is a nice idea for increased potential interoperability, but has
two side effects :

- Some information may disappear. E.g. the standard Keywords or
Subject metadata fields format supports only a flat list of keywords,
not a hierarchical structure.
So if you have a structured tag on an image,
say /Location/France/Paris, only the tail component Paris will appear
as a keyword and another application reading metadata will no longer
be aware of the former hierarchy.

(As far as I know, only the hierarchicalSubject field ensures
compatibilty with Adobe software, without structure loss.)


- This mechanism may overwrite some standard fields if you use other
metadata edition programs. E.g. editing image title and description
will keep compatibility with DK, but image subject edition would be
destroyed the next time DK saves a tagslist.
(I'm sure of that, I've already lost subjects:-)

And this is why defining item by item what is to be written, in the
Metadata settings folder, cf. supra, is a nice feature. (This is my
personal case; I save titles and descriptions, but as I happen to edit
also subjects of my own, I don't save tagslists not to destroy my
subjects. But it's a detail.)


Regards,
Jean-François