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 over 1 year ago. Updated 4 months ago.

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

0%

Estimated time:
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 over 1 year 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, 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 over 1 year 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.

#3 Updated by m laverdiere 11 months ago

According to the blog post related to new features in darktable 2.6 (see: https://www.darktable.org/2018/12/darktable-26/), the behavior for tag search is now the following:

The collect images in lighttable now has 3 modes to deal with hierarchical tags. When selecting a tag which isn’t a node leaf (i.e. a tag that has subtags), say, the “parent” tag:

A normal double-click selects only the images tagged with this particular tag. The search string is set to “parent”.

A control-double-click selects only the children, e.g. images tagged with “parent|child” but not “parent” only. The search string is set to “parent|%”, where “%” is a wildcard meaning “any string”.

A shift-double-click selects images tagged with the tag itself or any of its subtags. The search string is set to “parent%”.

While it might offer some more search flexibility/power, it does not answer the bug reported here.

The basic thing here is that we still need to have a consistent way to retrieve pictures/images with same tags, independently of the tagging sequence. Again, if Image 1 was first tagged Nature and after Nature|Flower (2 tagging steps), it should be retrieved the same way as an Image 2 that was directly tagged Nature|Flower (1 tagging step). Under the new search modes included in version 2.6, with "normal double-click" on tag "Nature" only the Image 1 would be retrieved, since Image 2 wouldn't have the standalone (without children) "Nature" tag.

#4 Updated by m laverdiere 4 months ago

As a complement on this bug report, see the discussion here: https://discuss.pixls.us/t/tagging-improvements-in-darktable-2-7/13571/14

Here are the mixed results of some testing with other DAM software, using the same example cited above:

-digiKam and Shotwell: not influenced by the tagging sequence, image 1 and 2 end up to be tagged identically, and can be retrieved with the same query (with only Nature or with Nature|Flower)

-ON1 Photo RAW 2019: image 1 end up with tags Nature and Nature|Flower; Image 2 only with tags Nature|Flower (so like current darktable), but both can be retrieved using only Nature in the query (unlike current darktable)

-ACDSee Photo Studio Ultimate 2019: behaves like current daktable, i.e. image 1 end up with tags Nature and Nature|Flower; Image 2 only with Nature|Flower, and only Image 1 can be retrieved using only Nature in the query.

Also available in: Atom PDF

Go to top