Along with taking the day for mental health and generally trying to be sane. I’ve been thinking about the future of how my photos are managed and how that needs to evolve.
The present system is pretty much this:
- Photos are cached to preferred cloud storage (+2 copies).
- One is cleared periodically ‘en mass’ after draining.
- One is cleared periodically during ‘archiving’.
- Photos are archived to my file server (+3 copies).
- Master copies under my Plex media library.
- Periodically backed up to another local location.
- Entire file server is backed up locally.
- Photos are archived unfiltered to cloud storage (+1 copy).
Now, there’s a few problems with this scheme. Aside from getting off my butt closer to quarterly or yearly than monthly to drain cached images into the master. Over the years the definition of 3 has changed a bit. Another problem has been the evolution of format: I’ve generally migrated from classic JPEG to HEIC, as I’m seeing on the order of 50% disk savings. But of course Plex doesn’t speak HEIC, and therefore viewing outside of mounting the network drive hasn’t worked in years!
I don’t think there’s a good solution to how often I process photos through this pipeline, relative to any other habitual behavior.
There’s also the fact that whether I am draining the cache or actively looking for images, such as building my ‘Remembering Corky’ or ‘Photo Frame’ albums, that doing this at OS level kind of sucks. Explorer and Finder have actually gotten pretty good at dealing with photos since circa 2000, but aren’t exactly fun. More than once I’ve wished for something like Geeqie that my previous Unix machines had. In suffering the native tools, I found that building my Photo Frame album was really damn painful in finder’s gallery view, until I decided to just copy everything to a memory card and go through a process of deleting whatever I don’t want to move.
Actually, the general work flow and process has sucked enough that I’ve considered writing a bit of software to help compensate, or transitioning my master copy into something more cloudy and photo centric. Something that can offer better navigation / movement than a file-centric manager and a little bit more database goodness than my Photos/${YEAR}/${COLLECTION}/ approach to on disk storage.
Then in putzing around Steam Deck, taking its desktop mode for a test drive made me remember an old KDE application called digiKam. It has features for basically everything but pulling free disk storage out its digital back oriface.
In the old days, I never messed around with digiKam. Partly because it and KDE, were kind of heavy weight on my laptop back when I was a KDE user. Partly because by the time digital cameras and smartphones were part of my life, I had no KDE systems and an increasingly heterogeneous computing environment.
I’m thinking that digiKam may be a good solution to the solvable problems. It certainly should be able to handle my photos archive, which is over 40G and 14,000 image and video files. Actually, when the heck did this get so large? It feels like just a lustruum ago, I could fit everything on one Blu-ray layer 😆. Actually, maybe I should run WinDirStat or Grand Perspective over that. On the flip side, digiKam will probably offer much of the goodness I remember Google+ Photos having back when I used that. For me personally, being both cross platform and open source are huge pluses. It’s also helpful that it is one of the more cross platform KDE applications, as KDE off Linux/*BSD has become a thing.
As far as I can tell, there’s two problems to this plan.
Problem one is the file wrangling. My photos will remain on my file server with its redundant 8 TB of storage, and the SQLite databases of digiKam are best kept locally. This means that it will need its own backup management. A simple path is using my Mac and its Time Machine destination for that. How well sharing digiKam’s database files across different systems, I’m not sure, but in any case the trend has been for me to prefer one set of muscle-memory.
Problem two is transient image management. See, most of what I do with images fall under two categories: either my master repo, or some pipeline stage denoted above; or ‘a directory full of stuff I want to peruse’. I’m not sure that digiKam really handles that perusal factor. One of the things that I liked about running Debian and FreeBSD on my laptops, was being able to throw geeqie at that problem. Although, it might be viable to just create a staging area and export things.
In any case, it’s looking like digiKam is probably the best non-proprietary solution for the photo management hoopla that doesn’t involve me writing code to scratch itches.