digiKam is the cornerstone of my photographic workflow. This powerful and versatile photo management application has all the tools and features necessary for transferring, organizing, processing, and managing photos, RAW files, and videos. But even though digiKam can handle practically any photographic task you throw at it, there is still room for optimizing and improving parts of the Linux-based photographic workflow.
Network and hardware setup
My photo library, and all digiKam resources (databases and configuration) are stored on an external USB 3.0 hard disk. The databases and the .digikamrc configuration file reside in a separate directory that is also a Git repository. This allows me to back up the important parts of digiKam on GitLab. Having the photo library and digiKam resources on an external hard disk makes it possible to manage and process photos on any machine running digiKam. I use a shell script to automatically mount the hard disk and launch digiKam with the configuration file stored on the hard disk.
To keep my data safe, I have a three-pronged backup plan in place:
- Backup on location When traveling, I use Little Backup Box to keep my photos and RAW files safe.
- NAS backup The contents of the hard disk are regularly backed up using rsync to a two-bay NAS with two disks in the RAID 1 (mirroring) configuration. I also back up the most important data to a SanDisk Extreme 1TB SSD that I carry with me.
- Cloud backup I use the rclone tool to back up the data on the NAS to the Backblaze B2 cloud storage.
Importing, organizing, and processing
Although digiKam features a rather capable import tool, I use the Otto shell script to import, rename, organize photos and RAW files as well as geotag them and write weather conditions and technical data into the EXIF metadata. For reasons unknown, I'm obsessed with knowing what the weather was like on the date a particular photo was taken. And to keep track of that I cobbled together a simple PHP-based application unimaginatively called Weather and notes. I also rely on another tool of my own creation, Konbini, for renaming, resizing, geotagging, etc. directly in the Dolphin file manager on KDE and Nautilus on Gnome.
Here is what my typical import workflow looks like. The INTAKE directory on the hard disk is the first stop, where all imported RAW files and photos are transferred. Otto then organizes them in sub-directories by date using the YYYY-MM-DD format.
The LIBRARY directory on the hard disk acts as the root album in digiKam. I move the RAW and JPEG files I want to process and manage in digiKam from INTAKE to the appropriate project sub-directory in LIBRARY.
Once the photos and RAW files have been transferred, I enable the MIME Type filter in digiKam to show only JPEG photos and quickly prioritize them using picks. I assign the Accepted pick to photos that are worth keeping and processing, and I use the Pending pick to mark photos that I plan to process later.
After the photos have been prioritized, I move the accepted images and their RAW files into the appropriate target albums. I prefer to organize photos by projects. To process the added photos, I enable a filter that displays photos flagged as accepted. Once the photos have been processed, I tag them. Each RAW file and its accompanying JPEG files are then stacked together using the grouping feature in digiKam. This way, each stack contains a RAW file, an original JPEG from the camera, and a processed JPEG (with the latter being on top of the stack). It's possible that a similar system can be implemented more efficiently using the versioning functionality in digiKam, but I prefer to do this manually.
Color labels help me to keep track of the current status of each photo. I use magenta labels for photos published on EyeEm and green labels for images selected for the EyeEm Collection.
When it comes to processing and editing, I rarely work with RAW files. Usually, I perform basic adjustments on JPEG files using tools available in digiKam. Cropping, perspective adjustment, rotation, curves adjustments, black-and-white conversion, and sharpen are the actions I use most of the time. When necessary, I use the Local Contrast tool (but only sparingly) as well as the distortion correction and color correction features. I also use frequently a handful of custom curve presets.
I use the excellent GPS Logger app on my Android device to record tracks in the GPX format. The app automatically uploads GPX tracks to my NAS every day. The Otto tool mentioned earlier makes it possible to geotag photos when transferring them from a storage card. The script can also handle multiple GPX tracks, which can be useful when my trips stretch over several days.
Sharing and publishing
EyeEm is my photo sharing platform of choice. While this service might not be as popular as Instagram, it has several important advantages. Firstly, it allows you to upload photos from the desktop, and the service features a solid upload tool. Secondly, EyeEm lets you sell photos, and it partners with Getty Images and Alamy to tap into their extensive network of photo buyers. While this is not a straight path to riches, having even the smallest passive income doesn't hurt. I also maintain a portfolio, featuring my favorite photos.
Since I left Facebook for good, I realized how much I liked a simple yet nice feature. Every day, Facebook would show me photos I took on this day a year ago. Although I wasn't sharing a lot of photos on Facebook, I enjoyed receiving these small greetings from the past. With Facebook banished from my life, I decided to build an open source tool that does the same with my local photo library. The result is Natsukashii, a simple tool that consists of two parts: a Bash shell script that finds photos taken a year ago, and a simple PHP page that displays the results. The shell script relies on standard tools that are available on most mainstream Linux distributions (ImageMagick, ExifTool, sed, seq, and find).