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

[Samuel Gilbert]

Hello,

  Is modifying tags in another software a common usage pattern?

  I can understand why someone would use an external photo editor such as 
Gimp or Photoshop, but personally I think that trying to manage your 
collection with 2 different "collection managers" is looking for trouble.  If 
there is a valid use case, then investing efforts to try to make it work 
smoothly might be worth it.  Otherwise, it's will require a lot of effort for 
not a lot of gain.

Samuel

On 2013-02-19 16:00:16 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 ?
> 
> 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