I've avoided tagging my images for too long...

I currently follow this workflow, which seems to work well for me:

  1. When I import photos, I sort them into YYYY-MM-DD folders.
  2. Once I import them into darktable, I tag them with hierarchical tags (e.g. Trips|Everglades) so that I can either filter by all trips or by a specific trip. This helps me narrow or widen my collection as I require.
  3. As I edit and select my photos, I use color labels to rate them (yes, I know there’s an actual rating system…I just find color labels to be easier to distinguish visually). Recently, I’ve started also using the “reject” option to filter out bad photos.
  4. Exported photos probably retain the tags, but I don’t particularly care at that point, since I do all of my development (at least so far) in darktable.

This system means that I’m always able to filter as narrowly or as widely as I require, and sort by how good the photos are, with very few clicks. Since I can also easily find a particular day’s photos because of the way I imported the photos, I’ve found I don’t really need any other tools to manage/organize my photos.

Very true. But on linux (at least - I think also on macOS?), you can do hardlinks (using a simple ln <orig> <dest>). But I do think tags are the better option in this kind of scenario.

My ‘semantic folder structure’ dates back to 2004. Looking for images can be fun and rewarding; oftentimes, looking for, say, a particular train image, I’ll run across travel/kid/grandkid images that take me back…

In addition to good memories, I ususalky find a photo or two that I originally passed on that I like now, and will post process and share.

I try to look over my entire catalog at least twice a year.

This thread got me doing just that. From 2004, one of my all-time favorite images. If you look at the exif, note the camera…

Squirrel !!!

3 Likes

The link doesn’t work for me; is the article available via another route ?

https://docs.kde.org/trunk5/en/digikam-doc/digikam/using-dam.html

2 Likes

Your first post sure is a helpful post; I clicked and went straight to it; thanks.

Please try this:
https://docs.kde.org/trunk5/en/digikam-doc/digikam/using-dam.html

1 Like

My brief metadata story:

  • My original image files are all write protected, because I do NOT want ANY image editing data and NOT any metadata in the files. Reasons for this: file protection, backup control/time and separation of edit vs tagging metadata.
  • I decided to use not only the internal database of software tools, but also XMP sidecar files for this. With this a switch to other DAM software is possible. A lot of media files do not allow embedded metadata and due to this I do not want additional metadata even in my JPG and DNG files.
  • I started with MediaPro, IDImager, CaptureOne, Lightroom and IMatch and was quite unhappy with their metadata handling. Some tools do not accept read-only files (error or ignorance) and others mix sidecar and embedded data storage.
  • With DigiKam (DK) I could recover most of my metadata from mainly sidecar, but also from some embedded files of my previous DAM tools. This ability of DK saved my “life”!
  • After switching to DarkTable (DT) I investigated, whether DK and DT could share the metadata. It is possible, but to my humble opinion it is a little bit risky, does not work for all tagging and is not really necessary. I prefer to separat DAM and image editing as much as possible.
  • Currently I am very satisfied, that DK and DT use different sidecar file “file.ext.xmp” and “file.xmp”. Why this? Because I can separate strictly the tagging information of DK from the edit information of DT.

To my experience that total flexiblity of Digikam to allow read-only, write-only and read-write of metadata from image files or sidecar files is a very very big advantage. You have to play with this and find your way!

2 Likes