[Digikam-users] How to remove "left behind" tag tree

[Elle Stone]

Remco, you are absolutely correct. Rewriting all the images is very,
very slow. A maintenance mode would be nice.

The slowness of writing to all the image files is one reason I've been
investigating using XMP sidecar files, as writing to a text file is
much faster than writing to an image file.  Unfortunately, apparently
digiKam doesn't reread the XMP files, so the XMP sidecar files can't
be kept in synch with the database.

I agree that changing your tag organization *ideally* should be done
rarely or never. However, in reality, figuring out how to organize
tags is an iterative learning process. No-one knows when they start
tagging images how they really want the tags to be structured. So tag
reorganization is essential for beginners and also for peope who've
been tagging for a while.

The last time I reorganized my tag tree was because digiKam doesn't
make it very easy to search on "not any tag in this entire tag tree".
So I broke the tag tree - which kept track of location by country,
stateprovince, city and sublocation - into separate trees, one for
country, one for stateprovince, etc.

Ideally all that location information belongs in the xmp metadata
fields (iptc-extended uses xmp rather than iptc):
xmp-iptcExt:LocationShownCountryName
xmp-iptcExt:LocationShownProvinceState
xmp-iptcExt:LocationShownCity
xmp-iptcExt:LocationShownSublocation

But I don't see how to get the location information where it belongs
using digiKam, as digiKam still wants to write location information to
iptc fields. And I don't know if digiKam can search on the
iptc-extended location fields, even if I used exiftool to enter the
information properly. So I'm using tags instead. Hence the tag
reorganization: I want to be able to easily locate images that don't
have complete location information.

Kind regards,
Elle

On 10/25/12, Remco Viëtor <remco.vietor at wanadoo.fr> wrote:
> On Wednesday 24 October 2012 20:36:30 Andrew Goodbody wrote:
>> On 24/10/12 19:21, Marcel Wiesweg wrote:
>> > See bug 268688 and some similar reports.
>> > Lot of work for a proper solution.
>>
>> Yes, it's a long standing issue. It means that digikam currently behaves
>> in a non-intuitive way. I suspect that many people are editing their
>> tags hierarchy without realising that any already tagged photos are not
>> being updated resulting in inconsistencies.
>>
>> It is the single biggest thing that I would like to be fixed in digikam.
>>
>> Andrew
>> _______________________________________________
>> Digikam-users mailing list
>> Digikam-users at kde.org
>> https://mail.kde.org/mailman/listinfo/digikam-users
>
> One of the problems you face in correcting this behaviour is that when you
> make any change in the tag tree, potentially ALL your images (or sidecars)
> will have to be rewritten. If you are doing some extensive re-organisation
> of the tree, this can happen multiple times. So simply synchronising the
> changes with the file metadata can get very, very slow (not to mention risk
>
> of write errors, but for that we have backups, in theory...). It will also
> feel very slow: you have a number of changes in mind, but after every
> chance you'll have to wait while Digikam updates the affected files
>
> I think something like this asks for a kind of 'maintenance mode', where
> changes are put in a queue, and when you exit the maintenance mode, all
> changes are made in batch (to both database and images). If you cancel
> maintenance, no changes will happen.
> That would allow each image to be touched only once at most, speeding up
> the whole process (*): checking what has to be done for an image only
> requires database access. In addition, if modifications of the tag tree
> outside maintenance mode are forbidden(**), it'll remind you that changing
> your tag organisation is something you should be doing rarely (IMO).
>
> (*) There's still a lot of images to be rewritten, but that happens at a
> moment where the user has finished changing stuff, so it won't interfere as
>
> much.
>
> (**) addition of tags can still be allowed, as it only affects selected
> images, and only adds to the metadata, nothing has to be removed.
>
> Remco


-- 
http://ninedegreesbelow.com
Articles and tutorials on open source digital imaging and photography