[Digikam-users] What is being/will be done about the tags management problem?

[Jean-François Rabasse]

On Tue, 19 Feb 2013, Marie-Noëlle Augendre wrote:

> The tags synchronization issue has been poisoning the life (OK,
> only the photography workflow ; -) ) of a number of Digikam users
> for several months/years and frequently re-emerge as a subject in
> this mailing-list. As for myself (and I think for some others,
> too) I've gave up long ago to try to manage my tags, and I am
> patiently (more or less) waiting for the situation getting better
> before doing a huge organization of my whole photobase.
> 
> Could the developers team tell us how soon the users can expect a
> solution to this blocking problem.

On Tue, 19 Feb 2013, Gilles Caulier wrote:

> The light is here. I'm aware about this problem. As we entry in a
> new students period, i will try to find people to investigate and
> fix it.

Hello,

a few comments about this problem which is - as Marie-Noëlle said -
reccurent on this list.

>From my humble opinion, it's not just a fix to software, it's a
software design strategy. I've been concerned too, for a long time,
with this issue and I had a look at the source code.
The code seems corrects, some design choices may appear more
questionnable.

1. Synchronization of tags between database and images :
When Digikam writes metadata to images (or sidecar files),
the written tagslist is the current database state,
so « export » synchronization is done.

When Digikam re-reads metadata, the tagslist is merged with the
current tags associated to the image. (This is in source file
metadatahub.cpp, in method MetadataHub::loadTags, it's an explicit
merge, new tags are added to the current tags from DB, not a delete
current and replace by new).
And there, « import » synchronization is not effective, the database
doesn't reflect what is into the images XMP sections.

I don't see very well in which use cases this merging is useful,
but why not, if it has been coded that way, it probably is.
But what should be choosen, replace or merge ?

At least, a simple fix could be an option in the metadata folder,
« upon read concat new tags vs. replace all current by new ones ».
And in the code, just a "tagList = loadedTagPaths" instead of merge.
This would guarantee the database reflects correctly what is found
from images and enforce reversible behaviour between « Write metadata »
and « Reread Metadata » .

2. Metadata interchange with other applications : This is another
tags related problems, due to the different tags storing formats.
When Digikam writes metadata, tagslist are saved in several possible
formats, the Digikam format, digiKam:TagsList, the Adobe LightRoom
format, lr:hierarchicalSubject, the Microsoft Photo format,
MicrosoftPhoto.LastKeywordXMP. So, the great thing is that other
applications will get the tags.

When Digikam re-reads metadata, reading is done with a priority
order. Look for Digikam tags, if found keep that. If not found,
look for Microsoft tags. If found keep that. If not found look for
LightRooom tags, etc.
(From source module dmetadata.cpp, method DMetadata::getImageTagsPath)

But this means that if someone tags an image with Digikam, then uses
later another application, e.g. LightRoom, and edit the tags,
when back to Digikam the older tags in Digikam format will be
reloaded, not the newer LightRoom tags.

I just signal that, but it's very difficult to fix at software
level. The only solution I can imagine would be to add into the
digiKam namespace a kind of modification date. Upon read, comparing
that date with the standard xmp:MetadataDate would allow to detect
that another application has been used and that it could be better
to load LightRoom tags first. But it's probably too rare a use case
to be worth the work. 
Software can't be magic and letting users know what they do, and
asuming what they do, is probably a simpler strategy.


In conclusion : I really think that tags problem should probably
require more accurate design definitions. What is expected, what do
people do with tags, what should be the expected behaviour, do a
majority of users work with different software and how should be the
interoperability strategy, etc. But clearly, it's not a bug, not at
all. It's design choice, and on the software planet, design changes
should come from requirements changes. IMHO.

Regards,
Jean-François