[Bug 268688] New: Write metadata to all images does not remove obsolete tags

[Patrick Scharrenberg]

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

--- Comment #19 from Patrick Scharrenberg <[hidden email]> ---
Regardless of the suggested switch for strong synchronisazion for the various
metadata keys in the settings dialog, I would expect DigiKam to strongly
synchronize the DB content to the key Xmp.digiKam.TagsList in the digikam
namespace of xmp, if metadata export is enabled.
This includes changes to all affected files when renaming/reoranizing tags.
Otherways there is no way to reliably reconstruct this information in case of
an incident to the DB and the people who use this feature would loose much time
(they spent into tagging) and faith in this software.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Mårten Jansson]

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

Mårten Jansson <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #20 from Mårten Jansson <[hidden email]> ---
Hi All, Is there any progres on this one?

/Mårten Jansson

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Oldřich Jedlička]

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

--- Comment #21 from Oldřich Jedlička <[hidden email]> ---
I would like to see some progres as well. Now I have to call `find -iname
"*.jpg" -execdir /usr/bin/exiv2 -d i {} +` to delete all tags on all images
(Digikam is the only application storing IPTC tags on my system) and then store
the tags using Digikam back to files. Strange is that Digikam is not able to
keep its own tags in sync.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Peter Albrecht-2]

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

--- Comment #22 from Peter Albrecht <[hidden email]> ---
I have described another "in-digikam-workaround" at bug #288842 comment #2.
But of course, the best solution would be if this issue is fixed.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Andrew Goodbody]

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

Andrew Goodbody <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #23 from Andrew Goodbody <[hidden email]> ---
I think that two or more ideas are being conflated here.
This is not a request for digikam to auto-remove tags that are not present in
the db. ie it is not a request for strong synchronisation of tags. That would
be the wrong way to fix this issue IMO.
It is a request for changes made to the tags hierarchy to be reflected in all
images containing those tags. So only those tags changed should be updated but
it should be done in all relevant images. It should not affect other tags
already applied to the image regardless of whether they exist in the digikam db
or not.
I struggle to believe that anyone would want the result of moving a tag in a
hierarchy to actually just be to copy it to a new location or if they delete a
tag, for it to not actually be deleted. Which is actually what the current
behaviour is.
If there is a desire to have a history of changes made to tags that could be
done as part of non-destructive editing and versioning. It does not mean that
this bug should not be fixed as requested.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[DrSlony-4]

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

--- Comment #24 from DrSlony <[hidden email]> ---
Yes, and because of this very old issue I consider digiKam's tagging
capabilities for new images functional but for already tagged photos completely
unusable. digiKam is primarily a DAM tool, and if tagging files causes a
cabbage-soup effect of duplicate old and new tags then the program's primary
function it broken.
Please prioritize this!

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Elle Stone]

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

Elle Stone <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #25 from Elle Stone <[hidden email]> ---
It is possible to rearrange tags on the tag tree and synchronize tags and the
database IF you let digiKam write to the images. The trick is to reread
metadata from the images to get all the mismatched tags into the digiKam
database, then select ALL tags (not just the unwanted tags) on the Filters pane
before rearranging and pruning the tag tree. Use a combination of albums and
tags on the left pane to actually select the files to work with.

Unfortunately the above process doesn't seem to work if you are only writing to
XMP sidecar files. digiKam doesn't seem to reread the XMP file and/or doesn't
seem to want to delete any tags already written in the XMP file.

I can see how some people might want digiKam to leave existing tags alone in
the XMP file, if other applications are also using the same XMP file. But for
myself, digiKam is the only application that writes to the XMP file and the
current behavior makes using only XMP files impossible if I want the XMP files
and the digiKam database to be in synch, which I do.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Oldřich Jedlička]

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

--- Comment #26 from Oldřich Jedlička <[hidden email]> ---
The problem is also that using _only_ Digikam to organise your tags is not well
usable. It is able to add tags well, but that is all.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[harry]

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

--- Comment #27 from [hidden email] ---
The bug also exists for deleting tags, they are not deleted from metadata.
As someone who has to work with a photo collection on multiple computers and
sometimes access photos using other programs, it really is a serious bug. (and
one of the very few reasons that I still need to use Windows)

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

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

--- Comment #28 from Marcel Wiesweg <[hidden email]> ---
Elle: The XMP sidecar problem seems to be unrelated. Please try to reduce it to
a simple test case and report a separate bug.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Elle Stone]

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

--- Comment #29 from Elle Stone <[hidden email]> ---
Marcel, per your request, I submitted a bug report:
https://bugs.kde.org/show_bug.cgi?id=309058

On 10/26/12, Marcel Wiesweg <[hidden email]> wrote:

> https://bugs.kde.org/show_bug.cgi?id=268688
>
> --- Comment #28 from Marcel Wiesweg <[hidden email]> ---
> Elle: The XMP sidecar problem seems to be unrelated. Please try to reduce it
> to
> a simple test case and report a separate bug.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[DrSlony-4]

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

--- Comment #30 from DrSlony <[hidden email]> ---
That is incorrect. I only store metadata in the image files themselves, not in
sidecar files. I cannot effectively delete tags so that they will be removed
from the images' embedded metadata. Removing the digikam.db file doesn't help
either as it will get repopulated with crap when the images are reread.

(In reply to comment #25)

> It is possible to rearrange tags on the tag tree and synchronize tags and
> the database IF you let digiKam write to the images. The trick is to reread
> metadata from the images to get all the mismatched tags into the digiKam
> database, then select ALL tags (not just the unwanted tags) on the Filters
> pane before rearranging and pruning the tag tree. Use a combination of
> albums and tags on the left pane to actually select the files to work with.
>
> Unfortunately the above process doesn't seem to work if you are only writing
> to XMP sidecar files. digiKam doesn't seem to reread the XMP file and/or
> doesn't seem to want to delete any tags already written in the XMP file.
>
> I can see how some people might want digiKam to leave existing tags alone in
> the XMP file, if other applications are also using the same XMP file. But
> for myself, digiKam is the only application that writes to the XMP file and
> the current behavior makes using only XMP files impossible if I want the XMP
> files and the digiKam database to be in synch, which I do.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Elle Stone]

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

--- Comment #31 from Elle Stone <[hidden email]> ---
On 10/26/12, DrSlony <[hidden email]> wrote:

> https://bugs.kde.org/show_bug.cgi?id=268688
>
> --- Comment #30 from DrSlony <[hidden email]> ---
> That is incorrect. I only store metadata in the image files themselves, not
> in
> sidecar files. I cannot effectively delete tags so that they will be
> removed
> from the images' embedded metadata. Removing the digikam.db file doesn't
> help
> either as it will get repopulated with crap when the images are reread.
>
> (In reply to comment #25)
>> It is possible to rearrange tags on the tag tree and synchronize tags and
>> the database IF you let digiKam write to the images. The trick is to
>> reread

See
http://digikam.1695700.n4.nabble.com/How-to-remove-quot-left-behind-quot-tag-tree-td4660139.html

About the fifth post down I posted step by step how to remove all the
outdated tags, if you are writing to the image rather than to an XMP
sidecar. The steps are not intuitively obvious, it's really easy to
miss a step, and sometimes a few outdated tags are still left behind,
necessitating a redo to get the remaining tags. But it can be done.

I moved/broke up a very large tag tree, with tags applied to around
3500 images, leaving behind duplicate, outdated tags in the images.
That was just last week using digiKam 2.9. So I experimented and
searched the internet and came up with a process that worked for me.
As a precaution, probably best to test the process on some throwaway
tags/images before deploying over important images.

Also see this post: http://duq.ca/duqamuq/?p=270. It's for an older
version of digiKam, but the process outlined looks similar.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Elle Stone]

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

--- Comment #32 from Elle Stone <[hidden email]> ---
See "Synchronizing digiKam 2.9.0 database and image metadata"
http://ninedegreesbelow.com/photography/digikam-how-to-synchronize-images-database.html
for how to resynchronize the database and the image metadata. This
only works if digiKam writes to the image files. It doesn't work if
digiKam writes to XMP sidecar files.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[DrSlony-4]

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

--- Comment #33 from DrSlony <[hidden email]> ---
Thank you for the guide Elle, I'll try it, but such things should not be
necessary, this should just work.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Elle Stone]

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

--- Comment #34 from Elle Stone <[hidden email]> ---
I agree with you, it should just work, and quite frankly, I don't
think my "workaround" is worth the hassle for anyone who does a lot of
tag-tree rearranging.

Sometimes even when all the tags are selected in the tags filter
before rearranging the tag tree, things still get out of
synchronization. This happened to me this AM and the only way I could
get digiKam to recognize the old tags still in the image metadata was
to delete the old database, create a new database, and then unassign
all the outdated tags, tag by tag, a tedious, slow process. I've
modified my guide to emphasize that the procedure isn't a real
solution.

On 10/28/12, DrSlony <[hidden email]> wrote:

> https://bugs.kde.org/show_bug.cgi?id=268688
>
> --- Comment #33 from DrSlony <[hidden email]> ---
> Thank you for the guide Elle, I'll try it, but such things should not be
> necessary, this should just work.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Sven-2]

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

--- Comment #35 from Sven <[hidden email]> ---
When i just migrated from f-spot to digikam some weeks ago, i thought digikam
is totally broken - i was doing so much rearranging (basically build the tree
as f-spot didn't put the structure into any tags, so i rearranged every tag. In
the end I exported
To me this behaviour is absolutely rediculus, arguing it is a feature seems
strange to me. New tags are written (nonexistance of tag not preserved),
removed tags are deleted (nothing preserved at all), but renamed/moved tags are
too important to be not-preserved...

Anyway, I'm attaching my workaround to this. Its a perl script using exiftool
to apply the tags it reads from the database. Its not beautiful (non-recursive,
fixed maximum depth tagtree resolving, dirty hacks about when to write the
metadata and the list of files (if -a is not specified) has to be given
newline-delimited, which only happens if I paste to gedit, not to the CLI. Yet
it allows you to either straighten the tags of your full collection or to a
digikam-selected subset. Maybe its helpful to someone else, too.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Sven-2]

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

--- Comment #36 from Sven <[hidden email]> ---
Created attachment 77121
  --> https://bugs.kde.org/attachment.cgi?id=77121&action=edit
Script to manage tags externally to digikam. German details:
https://glumpundzeug.wordpress.com/2013/02/11/arbeiten-mit-digikam-was-es-kann-was-es-nicht-kann-und-was-man-dagegen-machen-kann/

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[tosca]

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

--- Comment #37 from [hidden email] ---
Is the issue solved in the 3.0.0 version?
I was waiting for it before doing a complete tags reorganization.

Marie-Noëlle

2013/2/11 Sven <[hidden email]>

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


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

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Sven-2]

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

Sven <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #77121|0                           |1
        is obsolete|                            |

--- Comment #38 from Sven <[hidden email]> ---
Created attachment 77122
  --> https://bugs.kde.org/attachment.cgi?id=77122&action=edit
attached wrong file before, sorry.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel