Version: 2.3.0 (using KDE 4.7.3) OS: Linux Using the tag-view on the left side of the screen does not remove the tag from the xmp container in the file. Reproducible: Always Steps to Reproduce: 1. Assign three tags to a picture: A, B and C 2. open the tag view on the left screen side 3. select tag "B" -> you can see your picture in the middle part of the screen 4. rightclick tag "B" on the left side, select "Delete Tag" and confirm deletion -> the tag in the left view disappears 5. select tag "A" in the left view to see the picture again 6. select the picture in the middle view 7. have a look at "Metadata -> XMP" on the right side: you can see "digiKam schema -> Tags List -> A, B, C" (Tag not deleted from XMP-Data) 8. now choose: "Image -> Reread metadata from image" -> tag "B" appears in the tag-view on the left side again Actual Results: After step 4. the tag "B" is still present in the XMP part of the JPEG. Also confirmed with a hex editor. Expected Results: After step 4. the tag should have been removed from the XMP container. I use "Metadata Writing Mode: Write to image only". The tags seem to be removed from sqldb, since digikam does not show them anywhere in it's GUI. But I have not looked at the database. Tags are also _not_ removed from XMP-data in the file, if you reorganise your tags via drag'n'drop in the tag-view on the left side. This bug seems to reside in digikam since 1.1.0. With this version I did some reorganisation as mentioned above and created some "ghost-tags" in June 2011. Using the "Caption/Tags" view on right-side to remove tags, works fine.
If you delete tag from tag view (left sidebar), until you sync file Metadata with Database using batch tool from Tools menu (option "Write Metadata to aLl images"), image metadata will not be updated. I know that Marcel work on this subject to process metadata in background when database content is changed outside right sidebar, or when digiKam is closed. I see some commits about between 2.3.0 and 2.4.0... LightRoom or Aperture work like this, especially when applications are closed : there are a process dialog to sync file metadata with DB. Gilles Caulier
Hi Gilles, I'm going to try digikam 2.4.0 the next days (have to install first). But for now, some further investigations with digikam 2.3.0 (according to your post): A) 1. assign tag A to picture01 2. delete tag A in the left sidebar 3. from menu: "Image" -> "Write Metadata to Image" => tag A still in picture01's XMP :( + an empty tag "" is written to picture01's XMP => from menu: "Image" -> "Reread Metadata from Image" shows a tag "My Tags" in the pictures tool tip (bad thing, since this will be hard to remove from the file's XMP again) B) 1. assign tag B to picture02 2. delete tag B in the right sidebar => no difference to deleting from left sidebar ----------------------------------------------------------- Workaround for deleting a tag: 1. filter with tag in left sidebar 2. select all images 3. remove tag in right sidebar 4. delete tag in left (right sidebar is disabled with no images selected) Move/Rename can be done: 1. create new tag 2. filter with old tag in left sidebar 3. select all images 4. assign new tag 5. remove old tag in right sidebar 6. delete old tag Since I don't have to delete/rename/move tags in the tag tree very often, I can live with this workaround. But you have to be aware of this pitfall.
I've checked this bug with digiKam 2.4.1 and KDE 4.7.3: => It is still valid! No difference to digiKam 2.3.0. Same behavior. Rating this bug: (You can work around all the problems that may occur from this bug) In my opinion, having some old tags lingering hidden in your images and popping out some time in the future is not nice, but it is not critical either. You just delete them again, when you find them, and everything is ok. Having an empty tag ("") been written to the picture's XMP data (see comment #2), can be healed the following way: 1. Search for all pictures in your collection ;) 2. in thumbnail-view select all 3. right-click one of them 4. choose: "Remove Tag" -> "" (the empty tag)
(In reply to comment #1) > I know that Marcel work on this subject to process metadata in background when > database content is changed outside right sidebar, or when digiKam is closed. I > see some commits about between 2.3.0 and 2.4.0 Reading this, I think about a syncing tool, which tells you: "Hey, 'picture001.jpg' has tags 'A', 'C' and 'D' set in its XMP-Data, but tags 'A', 'B' and 'C' set in your digiKam-DB. Do you want to: 1. copy the tags from file's XMP to digiKam-DB 2. copy the tags from digiKam-DB to file's XMP 3. write the intersecting set ('A' and 'C') to both digiKam-DB and file's XMP 4. write the union set ('A', 'B', 'C' and 'D') to both digiKam-DB and file's XMP But I could not find such a tool in digiKam's main menu. (Explicit Sync) Closing digiKam, manipulating a file's XMP tags outside digikam and starting digiKam again also did not bring up such a dialog or change the tags in digiKam's DB. (Automatic Sync)
(In addition to comment #4) Please don't misunderstand me: Comment #4 was not meant as an accuse. I just thought this syncing mentioned by Gilles would be great, so I tried to trigger it. The result: It does not seem to be release/activated yet. And as great fan of open source, I wanted to share this result.
(In reply to comment #1) > If you delete tag from tag view (left sidebar), until you sync file Metadata > with Database using batch tool from Tools menu (option "Write Metadata to aLl > images"), image metadata will not be updated. To be complete: Working on my test-system with a smaller digiKam-collection, I tried the solution "Tools" -> "Write Metadata to all images". This gave exactly the same result as written in comment #2. I would have been surprised by "Tools -> Write Metadata to all images" being implemented differently to "Image -> Write Metadata to image"
Old problem, solution is not trivial *** This bug has been marked as a duplicate of bug 268688 ***
Yes, Marcel : old problem, and old discussion... Some people want to preserve old tags, some other no. Personally, i prefer to have the strict duplication of tags between DB and image metadata. Perhaps the ultimate solution is to provide an option in metadata panel for this behavior. What do you think about ? Gilles Caulier
Fixed with #268688