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 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.
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;
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 ?
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.
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?
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.
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: people|family|smith|bob
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: people|family|smith people|family|smith|bob
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).
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.
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?
