DT: tagging: How do the properties of a tag differ based on its purpose?

Software darktable
1

The manual states, “tags are usually shared between multiple images and are used to categorise and group them.”

I am unable to build a definite, unambiguous picture in my mind of what this means. Would someone be willing to explain the difference between a tag whose purpose is to ‘categorise’ versus one whose purpose is to ‘group’ images?

Or am I incorrectly reading ‘to categorise and group’ as 2 options (to categorise OR to ‘group’), when it should just be one?

For example, I have a population of objects, of a wide variety of shapes. I can logically categorise, or label, my objects on the basis of their shape; one of the resulting categories might be called ‘spherical’. I can also physically gather objects together, in a group by shape, resulting in one of my gatherings having only spherical objects. What additional ‘information’ do I gain by having the concept of both a category and a group (in this case for spherical objects)?

Is this an issue caused by not setting the specification of ‘category’ adequately? For example, would I have been better advised to set the specification for ‘category’ to ‘object’ rather than ‘object shape’, thus allowing me to distinguish between the entities in my total universe (e.g. object versus ideas, colours, events …).? But isn’t ‘group’ then nothing more than a sub-group of ‘category’? Or, in other words, isn’t a ‘category’ the same sort of ‘thing’ as a ‘group’ - just a ‘super-group’?

2

With a tag you group images (all with the same tag go together), and you add them to a category (separating them from others that do not share the tag). Hopefully, the tags also have some semantic value (i.e. locations, not just tag1, tag2, …)

I think you are (again) overthinking the issue.

3

This may be a ‘chicken:egg’ situation: I’m overthinking because it’s not clear to me; it’s not clear to me because I am overthinking.

But having (for instance) flagged a tag as a ‘category’, what additional ‘information’ have I gained that I could use in, say, searching for images that satisfy certain criteria?

This questions nags at me because the number of keywords I assigned in LightRoom was legion - way out of control after 10+ years of fiddling. dt very kindly retained all of them when I migrated. Now I’m trying to reduce that by an order of magnitude, so any mechanism which enhances the hierarchical trees I am building would be helpful. I can’t see where ‘categories’ does this.

4

Did you read the information in the manual (https://docs.darktable.org/usermanual/3.8/en/module-reference/utility-modules/shared/tagging/.

In short, marking a tag as a category influences how that tag is stored in the XMP file. It doesn’t really help in searching.
Note that you can also mark tags as “synonyms”, which should influence searches.

5

Yes, repeatedly, over a considerable period of accumulated time spread over the last week. My brain is finding logical inconsistencies which it has not, so far, been able to rationalize, even with the assumption that the error is mine. I’m just about to pen another post with an example and seek clarification, once I have studied the manual again.

you said: “In short, marking a tag as a category influences how that tag is stored in the XMP file. It doesn’t really help in searching.”

Well, this intrigues me: I am unable to find anything in the manual that discusses how a category tag is (differently) stored in the XMP, nor how that can be exploited. And I am interested to note that using a ‘category’ tag doesn’t materially enhance searching, so I’m struggling to find an application for this classification of tag.

I haven’t fully understood how ‘synonyms’ can help me by enhancing searches, but it sounds interesting.

6

Quoting from the manual page I linked to earlier (under “edit/rename tag”):

Synonyms would help if you have created different tags with the same meaning (e.g. “kids” and “children”, unless those have a different meaning for you). You can either retag one of them, declare them as synonyms, or remember to search for both…

7

Super: you have described my situation quite appropriately: I had been going through the tedious process of displaying all the images tagged with one of the (undesired) synonyms, then applying the tag for the desired synonym to all those images, detaching the undesired synonym tag and then deleting that tag. Repeat at infinitum within and across synonyms. It sometimes happens that dt apparently gets its knickers in a twist during this process, but always recovers completely by an application restart.

The application of the label ‘synonym’ to the tag will be a quicker solution. My ability to remember to search for both - across a large portfolio of tags and synonyms - is best not relied upon!

All this work has thus far been carried out in my Windows install (because it has a nicer screen without a central-heating type fluorescent backlight), but I really hope there is an easy way I can export my keyword/tag taxonomy to Linux - is there ? Or am I going to have to copy over the entire portfolio of XMPs ?

8

According to the manual, there is a way… Same page I linked to earlier, a bit further down. But you read that already…

9

I find that quite extra-ordinary: I’ve been over this page about half a dozen times but for some reason these words just never registered… Simple explanation though: age.

I’m going to assume that ‘Import from dt’ is entirely functionally equivalent to 'import from LightRoom".

10

I don’t know if you still need explanation…
Setting a tag as category has the effect to forbid its exportation (when you export an image). So the main purpose of category is to allow you to structure properly your tags (tree structure) without the risk of cluttering your exported images with information which are useless for the images consumers.

1 Like
11

I fear this may be a permanent state! So, thanks for the additional clarification. At my current level of understanding I do not see the need to use the ‘category’ designation as none of the victims recipients of my exported images have ever requested tagging information. I do wish to make heavy used of hierarchically structured tags though - but this does not mean I have to use ‘categories’ - does it?

12

Following the recommendation from @paperdigits, I want to ask, here, a further question about tagging:

Could somebody definitively clarify for me which is the correct symbol to use when creating a hierarchical path for a tag? I fear some of mine are wrong, mainly because I do not understand the difference between what I call a ‘broken bar’ symbol and what I call a ‘vertical bar’ - which I think is the ‘piping’ symbol used in Linux and Windows commands. I am assuming I should be using the ‘piping’ symbol, to match that shown in the guide.

The other reason I may have been using the wrong symbol is that on 2 of my keyboards these two symbols are, unbelievably, on the same two keys, but reversed.

(On my ‘Linux’ keyboard, the ‘broken bar’ is on the leftmost key of the upper row of the ‘typewriter’ section of the keyboard (with the 1 to 0 keys). It is activated by using the ‘Alt Gr’ key at the same time. The ‘vertical bar’ symbol is between the left Shift key and the ‘Z’ key, on my UK keyboard. This key arrangement is exactly reversed on my Windows keyboard.)

By the way, I get this warning message when trying to edit a path:

Screenshot from 2022-01-06 10-13-51

Should the words ‘rename path’ really be ‘change path’ (or vice-versa)? ‘change path’ is the only relevant edit option I can find.

13

The tags hierarchy is valid and sufficient in itself.

Pipe character is not allowed in “edit” tag, but it is in “change path” (only present in tree view). “change path” is the main way to modify the path hierarchy.

14

You don’t need to, but it’s a small additional step that could simplify your life in the future.

Suppose you have a hierarchy that says:

Places | Argentina | Bariloche
People | Family | Cousins | John Doe

All normal tags, no categories. As long as you don’t export the tags it’s OK.

Now suppose you want to give John his picture taken in Bariloche, correctly tagged. If you export with tags you get ‘Places, Argentina, Bariloche, People, Family, Cousins, John Doe’, which has several tags that are useless. You can actually export only the last tag, but that gives you only ‘Bariloche, John Doe’, which may be too few.

Defining some of the nodes as categories you can define exactly what to export. In this example, you could define Places, People, Family, and Cousins as categories, and on export you get ‘Argentina, Bariloche, John Doe’.

Now imagine your hierarchy is much more complex, with multiple sub-levels and lengths of branches, and that also has ‘private’ tags that should only be exported on personal pictures but not on public ones. Correctly defining categories and private tags allows you to just export the image and be confident that you get exactly what you want at all times.

Yes, you can do it afterwards (tag type can be edited), but the more complex the hierarchy gets, the better is to plan it before than doing it in a rush when you need it. For example, I have an export preset for ‘Long term personal backup’, wich includes all tags on the JPG (including hierarchical and private tags), and a ‘Share’ preset that only includes non-private non-category tags, without the hierarchy. On export I just select the correct preset and don’t think about it.

4 Likes
15

Excellent post - thankyou. You have perceived that I really don’t understand what differentiates a tag which is a category from one which isn’t. I had tried to express that lack of understanding in this post, as well as others, but no strongly enough. Your response gives me something to study at length -and to hope the a full understanding comes to me!

16

As far as I know, the difference between types of tags on darktable only makes sense on export.

You first need to understand that there are two more or less standard fields in the exported file metadata where tags can be saved:

  • Xmp.dc.Subject: accepts only a flat list of tags, like tag1, tag2, tag3. This is the field one usually thinks of when talking about ‘keywords’ associated to an image.
  • Xmp.lr.Hierarchical Subject: accepts a list of tags organized into a hierarchical tree, like tag1|subtag1, tag1|subtag2|subsubtag1, tag2|subtag3. This field is maybe more technically oriented, and best used when there is a standardized way to treat the metadata.

Correspondingly, in the metadata preferences of the export module you can select to include the following things in the exported file:

  • tags: exports to Xmp.dc.Subject a flat list of all non-private and non-category tags
  • private tags: in the flat list above, also includes private tags
  • hierarchical tags: export the tags to Xmp.lr.Hierarchical Subject as a hierarchical tree, including category tags when needed to form the branches.

Note that category tags are never exported to Xmp.dc.Subject(†), they’re only included as part of hierarchical tags in Xmp.lr.Hierarchical Subject.

(†)Note: in version 3.8.0 there is a bug which makes this true only if the omit hierarchy option is also selected. This is fixed in master.

3 Likes