Tagging improvements in darktable 2.7

The menu entry “copy to entry” can be used for these purposes.
When the tag is copied, the filter … filters.
Then you can modify the copied tag to create a new one (button new). In fact that was my first intention to create easily very long tags.

For the size, I would like it higher too, but we have to keep it inside the window for all. If I find the way to make the height modifiable I’ll do it.

1 Like

Hi thanks for the reply. I meant something else regarding the idea to filter on a tag, my bad. I was rather suggesting to filter on a tag as a way to display the images in the database associated with that given tag. Selecting that option would copy paste the selected tag to the filter window located at the left of the light table. Maybe navigate to tag would be a better name for that function. It is a shortcut which i find convenient in lightroom when organizing/browsing tags. In darktable, it would reduce to one click the navigation to the content pointed by a tag as opposed to selecting the tag filter in the filter window at the left and then navigating to a tag in that window. I understand that may not be the intent behind the work you are doing at the moment. But it felt important to communicate the idea.

As for the create sub tag option, it works well with the copy button. For me the glitch was the default character used in darktable to indicate a sub tag, I never remember where it is on my keyboard. It’s a small detail. What I do is copy paste another sub tag structure and change the name. I just thought a create sub tag could be used in conjonction to the actual solution.

Can’t wait to see what’s next! thanks!

You can already do that in the collections module if you set the criteria to “tag.”

I understand this function already exists in the collection panel. I’m suggesting a shortcut to quickly display the pictures associated with a tag while browsing/managing tags in the remodeled keyword panel. Its a handy quick shortcut type of feature.

To keep a lean interface, Instead of being handled in a new menu entry, it could be that the copy to entry menu entry also copies the text in the clipboard so one would only have to paste it in the collection panel at the left of the screen. Just an idea.

This is an interesting feature, a bit redundant with collection. In fact we could call the collection to do that. But to be effective, we must be able to go back to the previous screen as fast as we have gone. An idea to put on the list.

1 Like


I really appreciate all these improvements with the darktable tagging process, which is quite powerful, but was somewhat rigid and sometimes difficult to manage, especially with modifications to tag names or hierarchy. Great to see that things will become more flexible. Many thanks for your hard work!

Now, I don’t know if it fits in the scope of your work, but I would also suggest to take care of come incoherence in the tagging process, that I have reported here: https://redmine.darktable.org/issues/12132#change-36848

Basically, for 2 images that share the same tags, a user may not be able to retrieve them both with the same query if the tagging sequence is not the same for each of them.

Here’s the example given in the bug report:

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:

Image 2:

See also how darktable handles search for hierarchical tags: https://www.darktable.org/2018/12/darktable-26/

Anyway, thanks again for your work!

One thing I miss is a tag overlay on images in lighttable mode.

I do select several images and than use ctrl+t or lua scripts with shortcuts to assign tags (quicktag, copy_attach_detach_tags). After a while it is hard to keep track of which images have which tags.

I would not agree with you. As the two images are tagged differently I find quite consistent the search makes the difference (if I’ve understood properly).
From my standpoint it’s up to you to detach the first tag when you have found a more appropriate/detailed one (if you wish).
Now I understand you would prefer a different behaviour.
We may have an option to detach the tag(s) on the path of newly selected leave ?
Or to have a button to clean-up all attached tags below of an attached one ?
But if you detach the newly attached tag afterwards you have lost the former one(s), which may be another unexpected behaviour (at least less secure).

The 2 images are not really tagged differently. They both have the tags “nature” and “flower” with the same hieararchy between “nature” and “flower”. It’s just the tagging sequence that is different…

I have a hard time to understand what would be a “real life” scenario where one user who assigned the same tags to 2 images, with the same hierarchy between thes tags, but in a distinct sequence, would want them to be treated differently when he performs a query… The tagging sequence should not make a difference here.

As far as I know, you won’t find this “behaviour” in other DAM software, like digiKam, Shotwell and others…

Anyway, thanks again for your work.

Faceted search is a thing, this is where the hierarchy of terms effects the results.

Yes, of course, the tag hierarchy should affect the result… not the tagging sequence!

In my example, the fact that the tagging sequence is different for image 1 and image 2 could only be that the user forgot to first assign the tag “flower” to image 1 and then come back later to assign this tag “flower”. Obviously, he wants image 1 and image 2 to both have the tags “nature” and “flower”, with the same hierarchy between these tags (i.e. nature|flower).


Totally agreed. But collection works independently of the tagging sequence, as far as I know.
But your example:

is not a question of different of sequence but a difference of tags. Am I wrong ?

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?