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

[Simon Cropper]

On 20/02/13 05:30, Elle Stone wrote:
> 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.

You would think that it would not be difficult or time consuming for DK 
to scan the albums and reconcile the various metadata repositories and 
provide a opportunity for the user to see those images that are 
out-of-sync (with subgroups showing why).

Out-of-sync files could then be inspected one-by-one using a tool that 
shows the differences between the database, image and XMP file and 
provides an opportunity for the user to select what data to keep. On 
exiting this routine DK would then synchronize all the repositories.


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