YYYY … year
event-name … something like “wedding-jane-joe”
NNNNNN … my unique 6-digit ID
MM-DD … start date of the content in that folder
description-of-content … anything short that will help me navigate the folders in an event
CAM … abbreviation of the camera used
The filenames are just the 6-digit ID, a dash and the number from the original filename or the negative.
The 6-digit ID is a continuation from assigning a number to every physical filmroll, it is basically just a running number assigned to a group of images. This requires some management of the numbers but it frees me from date-related naming schemes and makes searching for a group of tightly related images a blast.
This way every image has a totally unique number across the whole archive, every folder with images in it can stand on it’s own and the year+eventname folders above are just to bundle things together.
Tagging includes rough geolocation (words, never GPS data), names of people and objects visible in the image and a event-id (e.g. WEDDINGJANEJOE)
Yes, I do have such a structure, but I don’t know if it is useful. I have mixed feelings. The theory is, that tags could be combined in searches, which is unfortunately a bit cumbersome in darktable. However, separating keywords therefore makes sense. Therefore, I have event|birthday|2015|Name rather than an entire string. However, this is hard to remember and a flat structure may make more sense, having event, birthday, year and name as separate tags. However, this would interfere with the names of the subjects, therefore the hierarchy kind of makes sense.
In each event’s directory I have subdirectories for each type of source image, e.g., NEFs, JPEGs, MOVs. The top directory of the event contains 800x600 renditions from the source, or what I call “proof jpegs”. With my hack software rawproc, I can drag a proof JPEG to the rawproc window and it’ll open the source, usually a NEF, and apply the processing that rendered the proof JPEG. I can then modify that processing to make another rendition…
The only images that don’t end up in that tree are “technical” images, those taken as part of some testing or construction.
Like @chris, I like a flat structure, but I like it even flatter. I use RPD to import photos, and I pay no attention to any package’s facilities (filmroll, database, or whatever) for cataloging images. That way, my organization has no dependencies on what package(s) I use to work with the files. My file system is my catalog.
My naming convention for directories is yyyy-mm-dd_jobcode_camera
e.g., 2015-10-10_Haliburton-Sculpture-Forest_D7000
If a jobcode is something that may come up again, I can tell RPD to remember it, so if I visit the same area multiple times it’s easy to keep my terminology consistent.
My naming convention for files is yyyymmdd-hhmmss-seq-filename.ext
e.g., 20151010-165544-2562-DSC_0097.nef
So I can easily find things by subject matter or what camera I used, or even the file name from the camera (which might be useful if the SD card hasn’t been reformatted) with a simple ls command.
Like most here, I structure my photos into yyyy-mm $eventname directories. My own wrinkle is that I have a “default event” for each year, accidentally called yyyy $hometown, where all pictures go that were not associated with a special event.
Only exports are organized thus. Raw files go into unstructured daily directories in a separate directory tree.
For file names I generally use $originalname_$rating_$developer, which gives me an easy file-based way of searching for highly-rated pictures (*_4*), or pictures edited in Darktable (*_DT*). I keep the original file name as a prefix because (a) that makes finding the corresponding raw easier, and (b) it tells me the camera model, in a crude way.
My only real problem with the year/event scheme is that sometimes I’ll have images of other things in a given event, e.g., the pictures I took of mangled packages for refund negotiations before/after someone’s birthday party, my OCD about taking unrelated artistic images in the middle of an unrelated event - Squirrel!!!, so on…
Once I’ve rsynced to the backup computer, it becomes harder to segregate those, so I need some more discipline up-front…
I classify images by year, and place and/or topic. The topic may be an event. The squirrel picture would then to the directory for animals taken that year.
I am using digikam to index all my photos (using also face detection)
My choice of directory tree is as follows using exiftool :
Manufacturer / Camera / YYYY / YYYY-MM-DD /
Files are renamed on the fly like that:
YYYY-MM-DD_HH-MM-SS_Manufacturer_Camera_OriginalFileName.ext
no duplicates
very simple. i upload all the RAW files onto two different HDD. they RAw files are kept by their original dates. the exported Jpeg files are saved on two separate HDD there i save them by years. inside each year folder I have the photo folders in chronological order, numbered and a name given to them in order to ease the search.
I don’t structure my pictures by file or directory name, it’s too limited to search, or likely to be modified.
I also avoid modifying my image files by metadata (it also simplifies backups)
My pictures (raws and developed) are in more or less arbitrary directories (why name directories by date, when the system notes the creation date of each directory), like books to borrow, not directly accessible to the public in a library, whose number is only useful to the storekeepers (or to the machines…) to easily find a certain book. The readers who are looking for a book, and the people who establish the indexes, directories and catalogs are not concerned by this system.
To manage all this, I haven’t found better than kphotoalbum.
I totally agree, that’s why I started using metadata + tags to structure my images:
In the first place I use existing metadata to navigate through my photo-archive (datetime, lat/lon).
Then I tag all people with Person|Firstname Lastname
So I already have ‘who’, ‘when’ and ‘where’.
But ‘what’ and ‘why’ are still missing.
According to chris I will tag all images without people with a subject tag (for the ‘what’).
And according to the DAM Book 3.0 a way to structure the ‘why’ is the degree of intent:
‘where I parked my car’ → tag ‘Memo’
'memory images of friends, life events, business documents → tag ‘Event’
‘make a statement, express an emotion, art for arts sake’ → tag ‘Project’
So as mentioned above my current problem is how to structure my ‘Event’ tags.
At the moment, I don’t think I want to structure the tags with ‘date-hierarchies’ (like ‘event|birthday|2015|Name’), because it’s redundant.
But is it useful to find common Event-types for all images (like ‘Event|birthday|John’)?
Or do I just use the verbal description (Event|Johns first birthday), which would be a quite long unstructured list with hundreds of events?
While I do organize my images in darktable, there are reasons why a reasonable file system structure makes sense for me:
darktable only handles images, but I keep movies and audio recordings (all raw material I generate) in the particular event folders.
darktable refuses to read certain files, e.g. the panorama jpgs of my phone. While technically they count as broken, an adaption of darktables jpg reader was refused, but other software reads them without issue, such that I need to find them outside of darktable.
I can remember more easily which files are already in the catalog and such folders still have to be added.
darktables film rolls use the folder name.
It is easier to copy an event on file system level.
I leave all my pictures wherever they fall. I search, view and tag with XnView MP which has the best search function I’ve seen yet. I wrote my own hierarchical structure (text file) which can be found here:
I do not trust black box ‘system’, from experience, I prefer shelves and libraries rather than mechanical jukeboxes. Indexes can still be rebuilt, modified and reorganized.
Originals/2021/20211221/20211221_214600_00.DNG for raw files dating back to 2001. My first few years I used jobcodes in the day directory names, then I scratched it because it didn’t work (for me). I can shoot a myriad of different things in a day and descriptional metadata fits better in the original file or a sidecar.
Why the _00 before .DNG you ask? If there are two or more images taken the same second I need a two digit sequence. I don’t know if Rapid Photo Downloader can do that? Some cameras actually record SubSecTimeOriginal that seems tempting. But, as all cameras I’ve had historically don’t support it that would result in a mix of sequencing and SubSecTimeOriginal. Also, a future camera you buy might not support it, so I would really advice against using it for naming files. I’ve used exiftool forever and I do this:
The first round picks up still images (and videos) with DateTimeOriginal. The second round picks up video files that does not have DateTimeOriginal and uses MediaCreateDate instead.
Yes, year is in three places and month in two. Somehow I concluded this was a wise choice, perhaps I wouldn’t do it again. However, with this naming I’m never unsure what year or month I’m currently in.
Raw files exported to TIFF go in a directory structure parallel to Originals called Derivatives they are in full resolution. From these I create Delivery files.
That’s a good workaround for the problem of keeping file names unique when sticking with a strictly date-time-only filename format. But why not use sequence numbers? The site you link to in your post suggests exactly that.
A job sequence for the entire import or day uses more digits. For me I’d need four. Also, if you do some culling after renaming you’ll have large gaps in your sequence. Not aesthetically pleasing. But yes, I have images which only have _02 but not _00 or _01 because _00 and _01 have been culled post renaming.
That could have a practical explanation. The popular tools amongst professionals (like Lightroom) don’t support “sub second sequencing”. I don’t think C1 has it either. I could be wrong. Also, job sequencing works well. But, of course, I think my method is better.
However, with this naming I’m never unsure what year or month I’m currently in.
But yes, I have images which only have 