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

[Elle Stone]

On 2/19/13, Brian Morrison <bdm at fenrir.org.uk> wrote:
> On Tue, 19 Feb 2013 12:25:08 -0500
> Elle Stone wrote:
>
>> There is also the problem of keeping the database synchronized with
>> the sidecar metadata, if someone chooses to only write metadata to a
>> sidecar rather than risk writing to the image metadata:
>>
>> https://bugs.kde.org/show_bug.cgi?id=309058
>
> I don't mean to sink any ships here, but isn't this problem related to
> which programs support which metadata?

Well, there are all kinds of use cases and of course I am thinking
about my own use case. But I'm pretty sure I'm not the only person
using digiKam who doesn't let digiKam write to the image metadata but
instead uses sidecar files. So it seemed appropriate to bring up the
issue of keeping sidecars sychronized with the database.

FWIW, digiKam is the only program that writes XMP sidecar files for my
images. I don't use Lightroom. I do use Darktable on occasion, but
only as a raw processor, not for adding metadata.

>
> There are various types, metadata which is widely known about and
> supported for editing in multiple programs and there is private metadata
> which is only understood in one program (or maybe two). Unless there is
> a spec somewhere that defines the 'shared' metadata so that developers
> can implement support for it in their software then this circle can't be
> squared.

You are correct, of course. But I only want digiKam to square its own
circle. I want all metadata that digiKam writes to the XMP sidecar
file that digiKam creates (and that only digiKam writes to) to be kept
in synchronization with the metadata that digiKam writes to its own
database. I don't see how or why this should be substantially more
difficult than keeping the digiKam database in synchronization with
the metadata that digiKam writes to an image file. In either case, the
same problem of what to do with metadata written by other applications
(if the user chooses to allow this to happen) still remains.

> Isn't this exactly why sidecar files came about? A way of keeping data
> associated with a file in such a way that programs that don't know
> about it don't mess with it?

I was under the impression that sidecar files serve two purposes:
Provide a place to store metadata for file formats to which digiKam
can't write, or for which writing is still experimental. And provide a
place to store metadata if for whatever reason the user doesn't want
to write to the actual image file.

Kind regards,
Elle