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

[Gilles Caulier]

Jean François,

Please report this investigation in this bugzilla file :

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

Gilles


2013/2/19 Jean-François Rabasse <jean-francois.rabasse at wanadoo.fr>

>
> 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
>
> _______________________________________________
> Digikam-users mailing list
> Digikam-users at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20130219/562bb08f/attachment.html>