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

[Simon Cropper]

Based on Jean-François sequencing this would be my expectation (see 
inline comments...

On 20/02/13 02:00, Jean-François Rabasse wrote:
>
> 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 ?

The choice should be given to the user -- do you want to merge the 
metadata or replace all the metadata?


> 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.

Personally, my expectation would be that if the software detects that 
the metadata is different the user is provided an opportunity to chose 
which metadata to keep.


> 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.

The most important thing is that no data is lost. Whenever metadata 
change is detected the user should be provided an opportunity to review 
the changes and decide what to keep and what to chuck away. Of course, 
if the user prefers a straight up replace that is their prerogative and 
the import metadata from file option should do just that!


>
> Regards,
> Jean-François
>
>
> _______________________________________________
> Digikam-users mailing list
> Digikam-users at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-users
>


-- 
Cheers Simon

    Simon Cropper - Open Content Creator

    Free and Open Source Software Workflow Guides
    ------------------------------------------------------------
    Introduction               http://www.fossworkflowguides.com
    GIS Packages           http://www.fossworkflowguides.com/gis
    bash / Python    http://www.fossworkflowguides.com/scripting