On naming image files

Lounge
,
1

About a year ago I completely switched my photography workflow from macOS to Linux (opensuse tumbleweed) and consequently Digikam and darktable.
I can only be more than satisfied.
However, I noticed something I had never noticed before.

I save images in a filesystem sorted by date, such as:

$ ls -1  Memories/sessions/2024/
2024-01/
2024-04/
2024-05/
2024-06/
2024-07/

$ ls -1  Memories/sessions/2024/2024-04/
'2024-04-21 - Spain - Vinaros'/
'2024-04-22 - Spain - Valencia - Ciudad de las Artes y las Ciencias'/
'2024-04-24 - Spain - Vinaros'/
'2024-04-27 - France - Saint Raphael'/

$ ls -1  Memories/sessions/2024/2024-04/2024-04-24\ -\ Spain\ -\ Vinaros/
2024-04-24T10:21:17_X100F_000.jpg*
2024-04-24T10:21:17_X100F_000.jpg.xmp
2024-04-24T10:21:17_X100F_000.raf*
2024-04-24T10:21:17_X100F_000.raf.xmp
2024-04-24T10:21:33_X100F_000.jpg*
2024-04-24T10:21:33_X100F_000.jpg.xmp
2024-04-24T10:21:33_X100F_000.raf*
2024-04-24T10:21:33_X100F_000.raf.xmp
2024-04-24T10:21:33_X100F_001.raf*
2024-04-24T10:21:33_X100F_001.raf.xmp
...

As you can see my default for renaming files is.

[date: "ISO"]_[meta:Exif.Image.Model].[ext]{lower}

which is the default string I use in digikam to rename image folders.

All my image storage now follows this convention, and as long as I am on Linux (XFS filesystem) the file names are displayed correctly, especially the ISO date that contains the “:” character.
This is also true for backups/copies that are on a NAS (btrfs) that I mount via SMB and that display correctly on Linux.

Only today after about a year have I realized that macOS (APFS filesystem) does not display the file name correctly but replaces the “:” with “/” even when mounting the SMB folders.

Personally I liked the idea of using the ISO format precisely because it is a standard, a convention that can be useful in case of automation, scripting etc. but I would not want it to be more of a problem than an advantage in this case.

This is currently not a problem and I don’t want to rename everything again but I wonder if you guys follow different conventions and if you could share you opinion on this topic.

Thanks.

2

I use underscore or dash in place of slashes, colons, semicolons, etc etc. My file names are alpha numeric characters and dash and underscore for exactly this reason.

3

I know and I was doing something similar using dashes 2024-04-24T10-21-33_X100F_001.raf or using nothing 2024-04-24T102133_X100F_001.raf.

This was what I was doing before using the [date: ISO] parameter but they are not “standards” like the ISO format. I know this is nitpicking, but I don’t know how to explain this concept any better.

4

I’d say the important thing for file names are that you can understand what they mean and that you can parse them programmatically. I don’t see how using the iso format is beneficial.

5

Agree with the answer from paperdigits.

In theory you should not store metadata in the filesystem path, file names shoudl just be a rough indication of the content/context when manually browsing. Of course in practice this is sometimes much more simpler to use the filename to store metadata so you always have to find an healthy balance.

Coming from a VFX background I can recommend to have a look at what is done there as “inspiration” (of course mileage may vary): An introduction to organizing project files - La Cuisine

And if you want the super-nerdy approach which is rather just intersting to look at and not really doable for individuals: https://medium.com/blue-sky-tech-blog/a-rose-by-any-other-name-4b569309b575

The simple take from this is that as already mentioned by paperdigit any file location is only named with alpha numerical character (a-z, A-Z, 0-9) and underscore, dash, and dots (., -, _), this avoid any os incompability, and escaping issue for command line scripts and other programs.

6

Interesting resources, thank you for sharing them. Fortunately it was easy to remove the : from all files. Too bad I didn’t notice this detail sooner, but I actually prefer to make sure I don’t have problems and maintain compatibility with other systems.

7

Very similar approach, but I simply leave out the colons (even whilst having a 100% Linux workflow): yyyymmdd-hhmm-model-## in which ## indicates a sequence number. This is needed when taking more than 1 photo per minute; I guessed 99 per minute was enough)

8

In my workflow, the file names are almost irrelevant. I don’t care what they are, as long as they are unique within a folder. The metadata rules all. Once it’s in digiKam, I’ve found the actual filename doesn’t really matter.

That said, I do have a bash script that I use to import new images. The script creates a new folder under a digiKam monitored directory, it copies files from the SD, and renames them to yyyymmdd-shootname-origfilename.ext. It also runs exiftool to extract all image metadata and add my copyright info to the xmp. Once it’s in the digiKam folder, I start digiKam and begin working.

9

I use digikam as well and even if the name is irrelevant I want to be future proof. In the past I had a bad experience moving from Aperture to Capture One to Digikam/Darktable.

Pictures were managed in libraries and migration was painful.
I said myself to never use a library again and little by little I moved to a folder tree organised by year and monthly subfolders and sidecar xmp. I think it’s the most future proof solution.

I usually use exfitool to organise my pictures collections and it’s super convenient when I’m on the go to process lot of pictures.

As I said just above, my careless mistake was to use the “date ISO” function and I noticed the colon only after a year of use :slight_smile:
Anyway solved quickly but I like to read how each photographer has different needs and different ways to organize their image library.

10

I completely agree! I don’t want to be beholden to a catalog or a database. It’s too easy to corrupt.

I’ve configured digiKam so that ALL changes are written to the xmp sidecar. The sidecar is my source of truth. I also use Darktable for editing, so I’ve also set up Darktable to not use a catalog at all, and all edits are written to the sidecar.

Now, when I rebuild the DB (which I had to do about 2 weeks ago due to MariaDB issues in digiKam), I just rescan my image folder tree. It has all the metadata in the xmp files, and I haven’t lost anything.

Going back to the start of this thread, since all the metadata is in the sidecar, I really don’t care what the original filename was. It’s all in the matching xmp file.

1 Like
11

Probably of no help to someone who has chosen to use the operating system file-naming and directory structure for asset management, but …

Long ago, my files were scattered around on several drives. In the end, I laboriously put IPTC keywords in all my image files without moving or having to re-name anything. And I can move or re-name any file or folder and the file will still be found by XnView MP which has the best search engine on the planet!

With keywords, it is a good idea to keep and maintain a personal list rather dreaming up keywords on the fly.

Here’s mine http://kronometric.org/phot/XnKeywords.txt. Feel free anybody to download and edit it for your stuff …

1 Like
12

I like your list. One comment, though. Your “extraterrestrial” list isn’t what I thought. I was expecting E.T., Predator, The Thing, Superman, Michael Jackson. You know, real extraterrestrials.

Seriously, you’ve given me some good thoughts on how to expand my tagging, like adding weather conditions and seasonality. Thank you.

2 Likes
13

What do you consider to be the benefit of a “where” hierarchy in keywords compared to using iptc location related fields (Country, City, State, Province, Location, Sublocation,…)?

14

I am in my third year of a process to move my image processing from Windows to Linux. Strangely perhaps, but the visual image part of it does not concern me much, but as a long time user of Photo Mechanic, the metadata part of it does.

I am a keen reader of metadata related posts here and in other forums. This thread had me revisit a 2018 blog post by the metadata crusader Carl Seibert. I thought it was quite good back then, and I still think it is worth reading: https://www.carlseibert.com/keywording-considerations-start/

15

Probably depends a lot on the tool you use. With digikam it’s very tedious to set the iptc fields, so using tags is much faster/easier.

16

The benefit for me is that I only shoot around or near the property (I’m an invalid) so those IPTC location fields are overkill for me.

Plus locations are in a separate tab to keywords in XnView MP.

17

Metadata perspectives and workflows are interesting. It is often a balance of principles, effort and software. I am looking for “my way” in the jungle moving from Windows with Photo Mechanic to Linux with some other metadata tool(s).

Locations can be quite tricky. It used to be all about camera location. These days we have location taken and locations shown (note the plural). There are also locations related to the image in other ways. I kind of hoped you had a new location trick up your sleeve :wink:

18

Thanks a lot for that link. I recently tried to be more disciplined with assigning keywords, to make it easier to search my collection, but struggled with the question how detailed/fine-grained they should be (i.e. should I add a keyword for that specific bird, which I only have one photo of?).
Somehow I never considered the caption as a field relevant for searching but only to provide additional information to someone already viewing the image. However, after playing around with it a bit now, it is indeed a great way of providing additional search terms that would be too unique or fine-grained for keywords. So I think I’ll change my current system and start writing short captions for all my photos. And at the same time, reduce the granularity of my keywords.

19

I followed Seibert’s writings a lot when I started key-wording. Very helpful!

20

@pindakoe in digikam you can use:
[meta:Exif.Photo.SubSecTime]

to get the subsectime but not all the camera support this.

As an example, this is what I’m using to rename my files in digikam:

[date:yyyy-MM-ddThhmmss][meta:Exif.Photo.SubSecTime]-[meta:Exif.Image.Model]{replace:" ",""}.[ext]{lower}