Project

General

Profile

Bug #12132

Hierarchical tags/keywords: incoherent/unexpected behavior when applying first and second level keywords at the same time or not

Added by m laverdiere 4 months ago. Updated 3 months ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
General
Target version:
-
Start date:
04/13/2018
Due date:
% Done:

0%

Affected Version:
2.4.2
System:
Fedora/RHEL
bitness:
64-bit
hardware architecture:
amd64/x86

Description

Let's say I tag the Image 1 with the keyword Nature.

Then I tag the Image 2 with the keywords Nature|Flower.

Then I go back to Image 1 and I also tag it with keywords Nature|Flower

I will end up with the following tags in these images:

Image 1:
Nature
Nature|Flower

Image 2:
Nature|Flower

Before transitioning to darktable, I used other FOSS for photo management (mainly: digiKam, Shotwell), which would have lead to the following - more coherent/expected IMHO - results:

Image 1:
Nature|Flower

Image 2:
Nature|Flower

I think darktable should do as well.

This is not the same bug, but it is somewhat related to the same problem: https://redmine.darktable.org/issues/10447

History

#1 Updated by m laverdiere 4 months ago

I got some time to investigate more this issue and I now realize that issue 10447 is not relevant for what I'm trying to report here (speed reading may be hazardous!).

Now, after doing various tests with darktable and digiKam, I also figured out that, as far as sidecar xmp files are concerned, they seem to behave the same with respect to hierarchical tags. With the same scenario as the one proposed in the main report, I find that in digiKam, it leads to the same result than darktable in the sidecar xmp files, i.e.:

Image 1:
Nature
Nature|Flower

Image 2:
Nature|Flower

The important difference is that in digiKam, if you select the tag "Nature" (alone), Image 1 and Image 2 will show up, even if Image 2 doesn't have the tag Nature registered as a separate tag than "Nature|Flower". This is also true for Shotwell and, I suspect, for other photo management utilities.

Now, in darktable, things becomes more problematic since the release of version 2.4.3 yesterday, for which one of the advertised bugfixes (which look more like a regression to me...) is the following: "When collecting by tags, don't select subtags" (see: https://github.com/darktable-org/darktable/releases/tag/release-2.4.3).

What's that mean is that now, if I search in darktable with the tag "Nature" (alone), only the Image 1 will show up (unless you use a joker (%) in the search). IMHO, this is incoherent (and an unexpected behaviour), because if you take the proposed scenario in my main report, the only difference between Image 1 and Image 2 is the tagging sequence, not the user tagging intent. In this scenario, the user expected result is obviously that Image 1 and Image 2 should have the same tags and should be retrieved (collected) with the same tag query.

So, since version 2.4.3, it becomes more important that darktable has a coherent behaviour for hierarchical tags. It should still be possible to use a first-level tag (Nature) alone, but if a sub-level (Flower) tag is applied later, the result should not be different than what it is for an image directly tagged with first-level/sub-level (Nature|Flower)

Otherwise, with the current implementation, are we not loosing one of the great benefit of hierarchical tags?

#2 Updated by Tobias Ellinghaus 3 months ago

I agree that it's inconsistent, that's why the "old" behaviour up until 2.4.3 was to include sub tags. I personally don't use tags so I am not really suited to come up with ideas how to best solve this.

Also available in: Atom PDF