[Digikam-devel] [digikam] [Bug 337688] Reading/writing of keyword-tags to jpg and xmp corrupts tag hierarchy, duplicate root tag

Christian buitk14 at A1.net
Tue Jul 22 20:45:17 BST 2014


https://bugs.kde.org/show_bug.cgi?id=337688

--- Comment #8 from Christian <buitk14 at A1.net> ---
(In reply to Gilles Caulier from comment #4)
> veaceslav...

Another note on the topic:
--------------------------

Many simple cases have been fixed so far. Complex tag hierarchies never worked
for me on any digikam version so far. I have not tested 4.0, only 3.5 and 4.1.

Some symptoms smell like outdated chached models ore gui states at the time
when metadata is written back to the images.

An adequate testcase would be: 
..................................

Create tag tree with 8 branches, depth of 8 levels and 8 elements. 8 albums
with at least 20 images nested in subfolders on 3 levels (e.g. 20 Mpx jpgs). 
Use tags below and above the digikam root tag. Create an artificial digikam
root tag as well in your hierarchy.

1. Test CRUD operations - Precondition:

 - assign 2 random elements of first 3 branches to all pics, each from
different levels (usecase for "location", "person", "time" category)
Assumption for these tags: they will not be changed any more, and therefore
should stay unchanged during the whole test. Some images, and some complete 
albums should only use unchanged tags to check if reading/writing is stable
without any changes applied.

 - assign 2 random elements of branch nr 4 from all levels and assume these are
outdated and have to be removed from all images later on
 - assign 2 random elements of branch nr 5 from all levels and assume these
keywords have to be renamed, and some are moved to other positions in the
hierarchy
 - assign 2 random elements of branch nr 6 from all levels and assume these are
spacial keywords that have to be split to three different keywords later on
(rename old keyword, filter on new keyword, add another keyword to some images,
and remove the other one)
 - assign 2 random elements of branch nr 7 from all levels and assume these are
spacial keywords that have to be joined with two or thee different keywords
later on: filter on the keywords and add the one to be joined, then remove the
others from all images
 - assign 2 random elements of branch nr 8 from all levels and assume these are
keywords for events that will be filled up with additional keywords on all
levels which will be assigned to images in several steps later on. Also remove
some of the added sub-keywords from single images (will this delete them from
these images?) and some from all images.

2. Test CRUD operations:

Write and re-read metadata after creation of the initial tags before the
changes are applied: check before/after

Then perform all the changes in the keyword-tags as described in step 1, e.g.
remove the outdated tags from branch number 4 ... . 

3. Test CRUD operations - Postcondition:

Write and re-read metadata after creation of the initial tags: check
before/after

A possible method:

Make a copy of the latest tag tree - eg. store all tags in one image with all
tags available (xmp xml) to document a snapshot of the tag tree in the db.
Make a screenshot of the Tag Manager View as well, because this bugs are likely
related to gui/chache status (except duplicate root tag).

Then write metadata from db to all files. Remove tags in database and reload
metadata from all files.

Store all tags in another image with all tags available (xmp xml) and compare
the resulting tag tree, and also compare Tag Manager View with the screen shot
taken before.

Write and re-read metadata a second time without any changes: check
before/after

4. Try to delete a nested digikam root tag on the second level (will be created
because of the mentioned bug)

Write and reread metadata again: check before/after

5. Try to delete the digikam root tag on the topmost level

Write and reread metadata again: check before/after

6. Try to delete the "My Tags" icon (I was able to do so in earlier versions)

Write and reread metadata again: check before/after

I know this a lot of work (I lost 6 days to find out) just for jpegs with
embedded keywords. This test should be automated to keep the tag feature stable
in future releases. 

Unfortunately I cannot invest more time at the moment, but I will if this is
not working out. It is a very important feature for me. I migrated all assets
from lightroom some years ago and I dont want to go back to adobe.

-- 
You are receiving this mail because:
You are the assignee for the bug.



More information about the Digikam-devel mailing list