When importing photos into DigiKam, I want them to be renamed based on the ISO8601 datetime they were taken, ideally to millisecond precision to avoid conflicts when multiple images were taken in a single second. This has the nice side-effect that photos from multiple camera sources are guaranteed to be displayed in the correct order when browsing files, which is important and practical for me.

I started out using this custom file renaming template on import:

[date:"yyyy-MM-ddTHHMMss"]-[file]

as DigiKam’s [date] placeholder didn’t have an option for milliseconds, and I couldn‘t find a counter option which could handle my desired “append -# per-collision if this renaming scheme results in collisions”, so ended up just adding the entire camera-generated filename to the end.

Unfortunately, this led to my files all being in the wrong order, even from the same camera. I haven’t quite figured out why, but it seems that there are several different internal datetime values stored in the image files: file creation date (which is completely wrong), the values used in DigiKam’s [date] templates (which are mostly wrong), and the DateTimeOriginal values stored in Exif data, which are not only correct but provide sub-second resolution too!

So here’s the DigiKam import naming template which I will be using going forward:

[meta:Exif.Photo.DateTimeOriginal]{range:1,10}{replace:":","-"}T[meta:Exif.Photo.DateTimeOriginal]{range:12,}{replace:":",""}s[meta:Exif.Photo.SubSecTimeOriginal]

which produces ISO8601-ish filenames like this:

2023-06-16T143139s922.JPG

Broken down,

[meta:Exif.Photo.DateTimeOriginal]

evalulates to a string like

2023:06:16 14:31:39

but I don’t want colons in filenames for portability, so I take only the date part with {range:1,10}, replace the colons with hyphens {replace:":","-"}, add a literal T separator to avoid spaces in filenames, take the time part of the datetime and remove the colons completely, add a literal s separator to delimit seconds and milliseconds as I wanted to keep them separate but not use the typical . delimiter.

Ended up getting frustrated with the old version of DigiKam available on Kubuntu, so tried installing an AppImage. The state of AppImage integration with Kubuntu is abysmal, and I open DigiKam fairly regularly, so I finally tried installing AppImageLauncher, which is recommended by DigiKam and is supposed to be a good tool for integrating AppImages with the desktop environment (something which Plasma should surely do itself, if AppImages are really going to be part of the future of linux app packaging).

Unfortunately, installing AppImageLauncher completely broke my desktop environment, causing it to hang and preventing me from logging in. Looked it up and it was clearly related to whatever this issue is about, as moving .local/share/mime fixed it. Removing AppImageLauncher and the mime cache got things working again, and, lo, before it broke my system, AppImageLauncher had kindly made .desktop files for all my AppImages!

At this point I decided to take a more manual approach to integrating AppImages I cared about with my DE, so I added a link from ~/Applications (where I store AppImages and other applications not installed via the package manager) to ~/.local/share/applications, where .desktop files are kept. Having quick access to this location makes manually managing .desktop files much more bearable, and I went about improving the ones AppImageLauncher had made (e.g. adding version numbers to the names – I find it very useful to know what version of an app I’m launching).

So, back to DigiKam: at this point I had a DigiKam 8.3 AppImage installed and openable via launchers thanks to the .desktop file. It had to re-download the facial recognition files, but other than that picked up everything from before. However, in the main photo list view, the maximum size of the thumbnails was tiny.

I spent some time poking around in settings and tweaking the QT scaling factor via the .desktop file, but I’ll spare you the details. tl;dr: if you want the DigiKam 8.3 AppImage to let you see large thumbnails on a high-DPI screen, you need to check the following boxes:

• Miscellaneous → System → Use high DPI scaling from the screen factor
• Vews → Icons → Use large thumbnail size for high screen resolution

Restart DigiKam, and it should let you make thumbnails large enough to be useful. This is especially necessary seeing as how DigiKam’s photo list view has a horribly wasteful layout, with almost as much whitespace as photo surface area.