Tagging improvements in darktable 2.7

What I’m trying to say, is that, IMHO, it’s not desirable to end up with 2 images tagged differently, when it is (usualy/probably) not the intent of the user to have them tagged differently, but just a matter of the way (or sequence) by which they were tagged.

In the example, the user wants both images to be tagged identically, but for Image 1, he proceeds in 2 steps (first he assigned “Nature” and after, he wants to ad the subtagg “Flower”), as for Image 2, he proceeds in one step, with the tag and the subtag (Nature|Flower). It may just be a matter of realizing later that Image 1 should also be tagged with “Flower”…

I don’t have access to Lightroom, but for what I remember when I tried it and based on what I see on the web (like here: https://www.youtube.com/watch?v=9QC62axwq3o), if we were applying exactly the steps involved in the example I’m using, I think we would end up with 2 images tagged identically, that could be retrieved with the same query…

I understand your point but I’m not sure it “must” be like that.
If other people agree with @mlaverdiere please jump in. This function can be added.

In lightroom : image
This image is tagged twice, the others no.
If you click on the number “amis” you have only one image.

I’m OK with the way it is. If you traverse the tag tree, I’d expect the results to be narrowed by the hierarchy.

I agree that “traversing the tag tree” should narrow the search results.

The issue here - as far as I see it - is what happen when you perform a query on a “head tag” for 2 images that share the same tags, with the same hierarchy, but have been tagged in a different sequence…

I’ve just tried it in digiKam, in the same sequence described in the example, and the 2 images were tagged identically and could be retrieved with the same “query” (either by searching with Nature alone or with Nature|Flower (I can’t check with Shotwell, as I’m on a Windows machine right now and don’t have time to setup a VM)

In the case of darktable, currently, double-cliking (without shift/control) on Nature would retrieve Image 1, but not Image 2, while double-clicking on Nature|Flower would retrieve both images.

I’m not sure I understand your Lightroom example, but could you confirm that if you were following the same sequence than in my example, both images would be - or not - tagged identically and could be - or not- retrieved the same way?

That said, I totally understand that darktable could implement something different than other DAM software… it’s just that - it may be just me! - I find that currently, the result is not really coherent/intuitive for users.

Thanks for listening!

I did some further tests with other DAM software and here are the mixed results, using the same example as 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;


1 Like

Is there already an overlay feature in dt (I may have missed it) ?
If I understand you would like to have the tags list overlaying the image where the mouse is in lighttable, is that right ?
This list is already displayed in the first windows of tagging module. Is that not suitable ?

Thanks for your response!

It is just a personal thought and I never tried to explore following feature

In theorie you can overlay a text from a sidecar file. I never tried it. Maybe I should look into that and try to do a lua script which creates the files

Moving the mouse over each image is for sure what you can do. I find it quite hard to read the tags in the module. Quite often the tagging module is not visible as well.

the overlaying text from a sidecar file is the exact same information as the new image info


or the new new “quick” image_info module

but you need to generate the text file first (using a LUA script) and it does not come with tags and can not modified right now.

Why not allow tags within the new “quick” image_infos module in the darkroom mode (in my case placed under the image together with GPS data) and on a selected image in the lighttable mode?

Not exactly the suggested overlay, but would that help in your process ?

1 Like

Thanks for looking into this!

Good question. To be honestly I would not extend the image information panel as it already is quite long.

After some thinking about this I realized that a lua module displaying the tag list on the left side (or wathever position) also might be a way to go. (No need to put this into “darktable core”?)

In both cases you would need to move the mouse over the images to get the tags.

I can agree with that… Thanks for your answer.

That should do it.

To go:

and back:

1 Like

Great! Can’t wait to test it in action!

Thanks a lot!

There is a discussion on github https://github.com/darktable-org/darktable/issues/3206 for which the users standpoint would be welcome.

To resume, the new tagging system introduces the notion of category inside the tag structure. The question is about the nature of the tags which are in the path of a hierarchical tag. Should they be seen as category or keyword by default ?

For example people,family and smith in:
the new system (dt 2.7) considers them as category as long as there are not declared themselves as a tag.

Then people and family are categories while smith and bob are keywords in:

On the other hand the former system (dt 2.6) considers the tags in the path as keywords (except if ‘omit hierarchy in simple tag lists’ in configuration is set).

Any thought ?

I like them as keywords.

1 Like

FWIW (and that may not be much, since I don’t use tagging in dt), considering all tags in paths as keywords seems to me to be more flexible, particularly for users who may not be disciplined enough to stick to a rigid hierarchy.

What are the consequences of the change?

Changes have been merged (tags in the path keywords per default).
The consequence is probably less surprise for the current users of tagging and export of list of tags (Xmp-dc-Subject), as this keeps the previous behavior.
As that’s only a default setting, that shouldn’t impact the other features of new tagging.

So that means the only thing affected is the exported plain tag list, I still can have a tag /people/family additionally to /people/family/doe/john and use it for building collections? And I can as well omit having the family tag but still have the one with the name?

Yes. The only point is there is no category by default. A category must be declared.