tags make me crazy

[Frédéric Da Vitoria]

I finally managed to clean my tags.

Here is how I proceded: first, as Maik suggested, ensure there are no 
duplicates except at root level. Once this is done, simply delete the 
wrong tags from the root. If dK recreates a wrong root tag immediately 
after you delete it, it means that you missed a duplicate somewhere. I 
had found another way by dragging the wrong root tag to where it should 
be, thus triggering a merge, but I deduce from Maik's explanation this 
dK behaviour only triggers duplicates, so deleting a duplicate will 
always leave the original untouched, and simply deleting the wrong root 
tag is simpler than merging it.

Ensuring that there are no duplicates may not be easy, because there are 
situations where using the exact same name in different places is makes 
a lot of sense, but there is currently no way to get around this 
limitation in dK (at least not that I know of). For example, I had 2 
"piscine", one for our swimming pool, one as a general swimming pool 
tag. I had to rename one of those in order to ensure unicity.

I don't understand why dK does this. When I check A/A1/X in the UI, why 
can't dK simply do the same thing in the selected photos? I tell dK 
where tag X is, so why explore the full tags list? Why does it matter if 
there exists for example B/B1/X too? I guess such a complicated 
mechanism has been included deliberately, but I fail to see to what 
purpose. Note that dK does what I ask him to if I ask him to add a tag 
which is used in more than one place. In my example above, dK adds the 
tag A/A1/X to the selected photo. But it adds a tag X too which I did 
not as for. What for?

Here are some remarks:

 1. dK sometimes created duplicates not only at root level, but also in
    intermediate levels. Those "intermediate" duplicates were always
    somewhere in the path to a correctly placed tag.
 2. the tags created by dK by duplication have a character coding issue.
    I found that many (all?) the duplicated tags which contained
    accentuated characters had those replaced with an inverted question
    mark.
 3. when selecting a group of photos and changing tags in a way which
    affects only a subset of the selected photos, dK updates *all* the
    selected photos, not only the subset; I feel this is both
    unnecessary and wrong (nothing was changed in the selected photos
    which weren't part of the subset). Example: photo1 has tags A and B
    and photo2 has only tag A, I select both photo1 and photo2 and I
    check tag B, dK updates both photo1 and photo2, when actually only
    photo2 was really changed.


-- 
Frédéric Da Vitoria


On 07/12/2024 22:05, Frédéric Da Vitoria wrote:
> Hello Maik,
>
> my replies/questions below:
>
> On 07/12/2024 19:21, Maik Qualmann wrote:
>> Hi Frédéric,
>>
>> I can't find any errors with these images.
>>
>> The tag "piscine" is created by the image "piscine
>> 20200311_092408_vHDR_Auto.jpg" in the root as a single tag.
> Let me explain again, and expand at the same time:
> - I don't want the "piscine" at the root level, only as a hierarchical tag
> - the tag piscine has 2 "legit" positions: in Sujets/technique/piscine 
> and in Lieux|France|Charente Maritime|Le Mung|piscine.
> - I did not create the tag "piscine" at root level. dK decided to 
> create it by itself (but you have explained below how and why this 
> happens).
> - if I select "piscine 20200311_092408_vHDR_Auto.jpg " in the 
> thumbnails view and uncheck the root piscine, dK recreates it as soon 
> as I click on Apply. Again, I know now why, but I don't know how to 
> fix it.
>
> Hmm, BTW, I just copied those 2 paths above from "piscine 
> 20200311_092408_vHDR_Auto.jpg", and I notice the difference in 
> separators. I guess this can't be good, but do you know any method to 
> fix this? I guess that many photos are affected by this...
>
>> This is actually how it is shown in the metadata and can be easily corrected.
> Well, the method may be easy, but I am unable to find it. Could you 
> explain?
>
>> I don't have the tag "mésange bleue" in the root with this set of images.
> It is there. Search for "sange" and you will find it :-) Obviously a 
> character encoding issue, but here again I don't know what to do about 
> it. This could be inherited from the photo tagging software I used 
> before, but I don't have it any more.
>
>> Please note the following: you should always read an entry for tags in the
>> advanced metadata that supports hierarchical tags. Either LR hierarchical tags
>> or digikam TagsList.
> For several years now, dK has been my only way of editing tags. The 
> only other graphical tools I use are Gimp and Hugin (and sometimes 
> RawTherapee or darktable) and AFAIK none of those know what a tag is. 
> I never used hierarchical tags before, hierarchical tags were one of 
> the reasons I chose dK. Currently, dK is set to Xmp.digiKam.TagsList. 
> Here are my tags settings:
>
> Does Xmp.lr.hierarchicalSubject mean LR hierarchical tags? If so, 
> IIUC, I should uncheck this, correct?
>
>> Please note the following: if an image has a single tag entry, digiKam tries
>> to find the name in the digiKam tag tree. However, if this exists multiple
>> times in different hierarchies, the tag logically cannot be assigned to one. In
>> this case, the single tag is created in the root.
> I guess this is the cause of the issue.
>
> But how should I handle this? Should I ensure there aren't 2 different 
> tags at different places? How can I clean my tags even assuming I am 
> willing to replace Lieux|France|Charente Maritime|Le Mung|piscine with 
> Lieux|France|Charente Maritime|Le Mung|piscine_dv?
>
> Is there a tool showing which tags are "duplicated"?
>
> Shouldn't this dK behaviour be enhanced in the future? Imagine a tag 
> named "garden", there are bound to be many places in a hierarchy where 
> such a tag would be appropriate. And one would not necessarily be 
> willing to give a unique name to each "garden", because being able to 
> pull all the "garden" from all over the hierarchy could be meaningful.
>
> -- 
> Frédéric Da Vitoria
>
>> Maik
>>
>> Am Samstag, 7. Dezember 2024, 10:13:51 Mitteleuropäische Normalzeit schrieb
>> Frédéric Da Vitoria:
>>> Hello Maik,
>>>
>>> Thank you for looking into this.
>>>
>>> Here are 8 examples. I did not touch anything in them since the problem
>>> occured except changing their file names, and I did so after copying
>>> them into a directory outside of dK's scope. So these should exactly
>>> what dK sees.
>>>
>>> I included:
>>> - 4 photos with the "piscine" tag, taken with 4 defferent cameras, each
>>> time the "piscine" is duplicated
>>> - 2 photos with a "mésange bleue" tag, one where this itag is duplicated
>>> at the root level, one where there is only one copy of the tag; I did
>>> not do anything recently with those old photos so I don't have any idea
>>> why dK decided to duplicate those tags
>>> - 2 photos with a "macaque à longue queue" tag, one where this itag is
>>> duplicated, one where there is only one copy of the tag; I did not do
>>> anything recently with those old photos so I don't have any idea why dK
>>> decided to duplicate those tags either; here, dK duplicated tag under
>>> "animal" instead of putting the duplicate in the root.
>>>
>>> I noticed that the duplicated tags had character set issues (when there
>>> were non-standard characters, of course).
>>>
>>> Note that the problem occurs when I select a group of photos and edit
>>> the tags by checking / unchecking the tags in the right pane. AFAICT,
>>> this does not happen when I merge tags using "Tags" in the left pane. I
>>> guess I should refrain from using the right pane to edit tags until this
>>> issue is solved.
>>>
>>> https://drive.google.com/drive/folders/1K2Q9Nf0F-D5UEuVK8CqSX5SG_9P3eCsc?usp=sharing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20241211/5864df88/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: yO94Mw0FR0hkbB6l.png
Type: image/png
Size: 21042 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20241211/5864df88/attachment-0001.png>