Some work has been done on the tagging module adding a tree view of the tags (for hierarchical tags), give more informations about the usage of the tags (count, usage) and last, give the possibility to rename the tags and to modify the hierarchy.
It remains a bit of work:
improve the suggestion list. The idea is to provide a list of tags which are the most used with the already attached tags on selected images.
add synonyms
improve the control of exportation of tags. That’s maybe the where your feedback is the most important,
Today, the only option is “omit hierarchy in simple tags list” (when hierarchical tags are broken down into a simple tags list). The idea is to replace this by some options on the tags themselves. The 2 obvious tag options are:
category or helper. This tag is only there to structure the hierarchy of tags but is not a tag in itself. For example in color|white, color helps to group the colors but it doesn’t bring any information to the image. This is not exported.
private. This tag is useful for your personal usage of your database (find the images of your mother in law fro example) but you may not want to find the name of your relatives on the public place.
Once the tags are configured, we could have an option at export time to export or not the private tags.
That’s where I am. What are your suggestions, your needs ?
My take on this won’t help you for sure… because what I need is just for the whole tagging operations to be faster (a lot faster, like instantaneous).
I do appreciate the improvements you’ve already made (number of counts a certain tag has been used, hierarchical view, renaming) but I personally I would not be interested in suggestions and exporting tags.
Why faster: I switched a few months ago to the stable 2.6.2 version because the whole library management was very sloppy on my (non-sloppy) pc; I have discussed here on the forum about my problems.
The reason why I’m replying with a message that – admittedly – you could find not very helpful is just because I’d like to warn against feature overload that would perhaps kill usability. When testing these features please do remember about usage cases like very large databases (30-50k photos or more), with all the files stored on an external usb3 drive (while the actual database is stored on the internal, fast, ssd of a modern laptop). What I’ve just described is obviously my situation but I think it may be a typical setup of many other users.
I don’t know how much tagging were (is) slow for you. On my side I hardly see any delay with 50k images on a simple i5 (and db on SSD).
But the tagging module should be faster than before. Before, the two tagging windows were reinitialized (with database access) at each single image selection or tag attaching. Now the bottom list is reinitialized only in some specific cases.
If tagging is still an issue for you, could you be more precise about the operations or actions you would like to see faster ?
Thanks for taking the time to comment on my post! Yes I could try and be more precise (it looks like we have similar computers; mine is an Dell XPS15 laptop with i7 etc), but that would mean installing the provisional 2.7 from git master… and that has caused me lots of pain months ago as I said in my previous post.
Well I could try to make a backup copy of evrything etc – I could do thatl next week when I’m on holiday.
NB: I’m still looking for some reference (I’ve seen that in the past) of language markup on synonyms. This way some applications are able to present the images keywords in the user language.
Great that tags will be improved in the next version. Thanks already for that. I am not sure to fully understand what you are busy with but, for me, the best improvement would be to have a tree, similar to what is available in version 2.6.2 for selection but that would be editable, allowing to create / delete / modify tags from the tree structure.
That is a really great addition! What a nice surprise when I installed the new build. After using the feature in the last few days, I would have 3 suggestions. First, would be to make the tagging window a bit longer (and the filter window at the left for concistency) if that is a possibility. And secondly, upon right clicking on a tag in the tagging window, adding an option to filter the current view around that given tag (a menu entry called something like “goto tag” or “filter on tag”). Thirdly would be the ability to create a new sub-tag by right clicking on a tag, perhaps with a pop up asking for the name.
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.
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.
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.
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:
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…
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).
