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 ?
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:
Great! Can’t wait to test it in action!
Thanks a lot!
Cyrille
There is a discussion on github Tag export: "omit hierarchy" behavior can't actually be disabled · Issue #3206 · darktable-org/darktable · GitHub 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:
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).
Any thought ?
I like them as keywords.
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.
Thanks for the explanations. It seems the difference is hard to understand without trying it. Does declare mean I cannot write a|b|c but have to “declare” a| and a|b| in a separate dialog, but I still can enter a as a tag?
a tag a|b|c|d created (declared) alone provides an explicit keyword d and three implicit keywords (*) a, b and c.
if you want a to be a category you have now to create (declare) the tag a and set it as a category (or collection in your words or helper for others).
(*) before the change a, b and c were implicit categories.
NB: if you create a|b and a|b|c|d, then set b as a category, a will be an implicit category, b an explicit category, c an implicit keyword and d an explicit keyword.
Does that help ?
Yes, thank you so much 
. Seems we will have the manual ready if we continue like that 
.
With collection I meant a tag “search” in the collect images module. Now, the only missing link is how categories affect the search in this module and the wildcard handling there.
implicit wildcard (not needed), search is done through full tag names (whatever category or keyword) and synonyms. EDIT: in tagging module. this is different in collect module (which has not changed and doesn’t know the notion of category nor synonym).
Big thank you again. To answer your original question for the user perspective, I think I don’t care as both seem not to change my workflow in darktable. But still, the new tagging features ahead are great!
This post to provide some more information about new tagging categories coupled with metadata export configuration.
In the hierarchical view of tag dictionary the user can set any tag (at any level) as a “category”.
The main point to remember is that a category is never exported in a tags list (xmp.dc.Subject or $(TAGS)).
So the first application is to use category to structure your hierarchical tags without polluting the exported tags list.
Example: in places|India|Tamil Nadu|Kanchipuram|Kamakshi Amman Temple
I set “places” as a category (displayed in italic), keeping the four next levels as normal keywords (as such they will be exported in tags list (xmp.dc.Subject or $(TAGS)).
But you can make an ad hoc usage of this structure at images’ export time.
In metadata configuration the formula $(CATEGORY0(places)) provides “India” (to be placed in a country related exiv2 tag) or $(CATEGORY2(places)), “Kanchipuram”, (to be placed in a city related exiv2 tag)
The second usage of category is to define the metadata you need in your specific workflow(s) and to deal with exiv2 tags only at images’ export time. (This covers pretty well some lr collection use cases as well).
For example you can have two categories “agency” and “creator” in which you list the needed names, set also as category.
In that case they will appear in image information like this:
And of course you can use them in formulas at images’ export time.
NB: The list of exiv2 tags, usable in formulas, is today limited to the most current tags but it is easy to add new ones in future dt updates. Exiv2 site gives the complete list. A lot of them can be added to the dt list without any other change.
NB2: tagging module is not suitable to add free text metadata (i.e. specific to each image) like title, description, comments …
I hope that helps.
@phweyland will you also be able to use those category tags in the export dialog as part of the export file name?
