
<div dir="ltr">Jean François,<div><br></div><div style>Please report this investigation in this bugzilla file :</div><div style><br></div><div style><a href="https://bugs.kde.org/show_bug.cgi?id=268688" target="_blank" style="font-family:arial,sans-serif;font-size:12.571428298950195px">https://bugs.kde.org/show_bug.cgi?id=268688</a><br>


</div><div style><br></div><div style>Gilles</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/2/19 Jean-François Rabasse <span dir="ltr"><<a href="mailto:jean-francois.rabasse@wanadoo.fr" target="_blank">jean-francois.rabasse@wanadoo.fr</a>></span><br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>

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

<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

The tags synchronization issue has been poisoning the life (OK,<br>

only the photography workflow ; -) ) of a number of Digikam users<br>

for several months/years and frequently re-emerge as a subject in<br>

this mailing-list. As for myself (and I think for some others,<br>

too) I've gave up long ago to try to manage my tags, and I am<br>

patiently (more or less) waiting for the situation getting better<br>

before doing a huge organization of my whole photobase.<br>

<br>

Could the developers team tell us how soon the users can expect a<br>

solution to this blocking problem.<br>

</blockquote>

<br></div><div class="im">

On Tue, 19 Feb 2013, Gilles Caulier wrote:<br>

<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

The light is here. I'm aware about this problem. As we entry in a<br>

new students period, i will try to find people to investigate and<br>

fix it.<br>

</blockquote>

<br></div>

Hello,<br>

<br>

a few comments about this problem which is - as Marie-Noëlle said -<br>

reccurent on this list.<br>

<br>

>From my humble opinion, it's not just a fix to software, it's a<br>

software design strategy. I've been concerned too, for a long time,<br>

with this issue and I had a look at the source code.<br>

The code seems corrects, some design choices may appear more<br>

questionnable.<br>

<br>

1. Synchronization of tags between database and images :<br>

When Digikam writes metadata to images (or sidecar files),<br>

the written tagslist is the current database state,<br>

so Ť export ť synchronization is done.<br>

<br>

When Digikam re-reads metadata, the tagslist is merged with the<br>

current tags associated to the image. (This is in source file<br>

metadatahub.cpp, in method MetadataHub::loadTags, it's an explicit<br>

merge, new tags are added to the current tags from DB, not a delete<br>

current and replace by new).<br>

And there, Ť import ť synchronization is not effective, the database<br>

doesn't reflect what is into the images XMP sections.<br>

<br>

I don't see very well in which use cases this merging is useful,<br>

but why not, if it has been coded that way, it probably is.<br>

But what should be choosen, replace or merge ?<br>

<br>

At least, a simple fix could be an option in the metadata folder,<br>

Ť upon read concat new tags vs. replace all current by new ones ť.<br>

And in the code, just a "tagList = loadedTagPaths" instead of merge.<br>

This would guarantee the database reflects correctly what is found<br>

from images and enforce reversible behaviour between Ť Write metadata ť<br>

and Ť Reread Metadata ť .<br>

<br>

2. Metadata interchange with other applications : This is another<br>

tags related problems, due to the different tags storing formats.<br>

When Digikam writes metadata, tagslist are saved in several possible<br>

formats, the Digikam format, digiKam:TagsList, the Adobe LightRoom<br>

format, lr:hierarchicalSubject, the Microsoft Photo format,<br>

MicrosoftPhoto.LastKeywordXMP. So, the great thing is that other<br>

applications will get the tags.<br>

<br>

When Digikam re-reads metadata, reading is done with a priority<br>

order. Look for Digikam tags, if found keep that. If not found,<br>

look for Microsoft tags. If found keep that. If not found look for<br>

LightRooom tags, etc.<br>

(From source module dmetadata.cpp, method DMetadata::getImageTagsPath)<br>

<br>

But this means that if someone tags an image with Digikam, then uses<br>

later another application, e.g. LightRoom, and edit the tags,<br>

when back to Digikam the older tags in Digikam format will be<br>

reloaded, not the newer LightRoom tags.<br>

<br>

I just signal that, but it's very difficult to fix at software<br>

level. The only solution I can imagine would be to add into the<br>

digiKam namespace a kind of modification date. Upon read, comparing<br>

that date with the standard xmp:MetadataDate would allow to detect<br>

that another application has been used and that it could be better<br>

to load LightRoom tags first. But it's probably too rare a use case<br>

to be worth the work. Software can't be magic and letting users know what they do, and<br>

asuming what they do, is probably a simpler strategy.<br>

<br>

<br>

In conclusion : I really think that tags problem should probably<br>

require more accurate design definitions. What is expected, what do<br>

people do with tags, what should be the expected behaviour, do a<br>

majority of users work with different software and how should be the<br>

interoperability strategy, etc. But clearly, it's not a bug, not at<br>

all. It's design choice, and on the software planet, design changes<br>

should come from requirements changes. IMHO.<br>

<br>

Regards,<br>

Jean-François<br>

<br>_______________________________________________<br>

Digikam-users mailing list<br>

<a href="mailto:Digikam-users@kde.org">Digikam-users@kde.org</a><br>

<a href="https://mail.kde.org/mailman/listinfo/digikam-users" target="_blank">https://mail.kde.org/mailman/listinfo/digikam-users</a><br>

<br></blockquote></div><br></div>