Tagging improvements in darktable 2.7

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

grafik

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 ?
image

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:
image

and back:
image

1 Like

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.

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.

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 ?

1 Like

Yes, thank you so much :smile:. Seems we will have the manual ready if we continue like that :wink:.

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).

1 Like

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!