• Please use real names.

    Greetings to all who have registered to OPF and those guests taking a look around. Please use real names. Registrations with fictitious names will not be processed. REAL NAMES ONLY will be processed

    Firstname Lastname

    Register

    We are a courteous and supportive community. No need to hide behind an alia. If you have a genuine need for privacy/secrecy then let me know!
  • Welcome to the new site. Here's a thread about the update where you can post your feedback, ask questions or spot those nasty bugs!

what kind of filenames?

Jukka Vuorinen

New member
This is mostly not about DAM software. Most of this message is introduction and actually question is very simple: So, tell me about your filenaming scheme?

Is it important that every image has unique filename? I have always felt that it is, because I few years ago encountered situation in which client requested image named XYZ, and there was two images with same name, because I was using camera generated filenames and cameras counter was reseted for some reason.

Currently I rename my images with self made script, which rename then to YYYYMMDD_HHMMSS_shuttercount (e.g. 20100919_125804_39195)

Sometimes I shoot bursts, so even 8 images can have same timestamp, so YYYYMMDD_HHMMSS is not necessary unique. I also shoot with 3 DSLR so shuttercount is not necessarily unique (and if shutter brokes then shuttercount is probably reseted in repair). But timestamp + shuttercount should be always unique. (Yeah, I know, should...)

Currently I'm reviewing my workflow and would like to simplify it with abandoning my own script. I'd like to do whole renaming business in Lightroom. Now I'm just pondering do I really need unique filenames...
 
I don't rename files until I export them as JPEG or TIFF from Lightroom.

I move the files from CF cards to folders with names in the form <location>_<date>, or if from a studio shoot studio/<project name>_<date>, then import them in place to LR.

When I want files to deliver to a client or post on the web, I export only the specific files I want, into a sub folder called "Web" for JPEGs, or "TIFF" for TIFFs and use Lightroom's custom renaming capability at that time.

My export filenames are in the form <project name>_<sequence number> so the original file may be named IMG_2345.CRW, and the export file name (for client use) may be "Johnson Fiddle 001.jpg"

I use LR's keywording facility extensively when importing pictures, so I can then search easily later. I also use LR's Collections to make groups of pictures for specific purposes especially if the originals come from multiple folders.

I can still look at any of my pictures and tell where, or what project it came from. So I can find the appropriate folder even without Lightroom, but have no need to name files with any more info than that until I need them exported.

Incidentally, because LR can recreate any set of edits from its XML data, I no longer save the exported JPEGs and TIFFs. If I need them again, I simply recreate them in LR. An exception to this occurrs with client files, because they are burned to CD/DVD, I keep a backup copy of the client's disk for reference.
 

Doug Kerr

Well-known member
Hi, Jukka,
This is mostly not about DAM software. Most of this message is introduction and actually question is very simple: So, tell me about your filenaming scheme?

Well, another member here told me recently that I am only a snapshooter, and there is no reason anybody here would be interested in my file naming practices.

But you asked!

I hold all the original camera files on my hard drive (and on various backup media) with a filename derived from the filename applied by the camera. I build out the front end with a prefix digit, based on eh camera directory, so as not to have ambiguity when the camera numbering system "turns over" (I use mainly Canon cameras), and I apply an alphabetic prefix telling the body that was used.

Thus, if a certain shot from my EOS-20D was stored by the camera on the memory card in directory 458CANON, with filename IMG_5892.JPG, it becomes on my hard drive:

E35892.JPG

The "3" prefix is one less than the "4" in the camera directory number, "458" (since the first directory number assigned by the camera is 100CANON and I want my file numbers to start with 00001, not 10001.). The "E" is the code for this body. (On this type of camera, the last two digits of the directory are always the same as the first two digits of the file number, "58" in this case.)

Incidentally, I store these on the hard drive in directories whose span is 1000 file numbers (e.g., E35000.JPG through E35999.JPG)

All this is done automatically when I upload the files from the CF card using DownLoader Pro (by using various "tokens" which, in effect, construct a "script").

Now, when I process these files to produce "deliverable" images, I use various filename schemes, but the original primary filename is (almost) always embedded. For example, a deliverable generated from the file above might have this filename:

Clinton_wedding_E35892.jpg-02

The "-02" distinguishes this image from others derived from the same original frame, perhaps with different crops and so forth.

Thus, I can always trace back to the original file from a deliverable if I should want to make a new variant. This also helps if I should later want to see if there was, in the same shooting sequence, another frame showing something about which an interest is later expressed.

What happens of the numbering sequence in a camera is inadvertently reset? Hopefully I notice this, and reset the camera back to where it should be. (Sometimes that means I will have to rename some files already uploaded with "wrong" file numbers.)

There is no risk that, in the event of such an event, any existing files will be overwritten. The uploading program will not do that (without explicit permission).

Best regards,

Doug
 

Mike Shimwell

New member
I name files with the scan date, film type, iso index, development regime, location and frame number. Then, print files gain an individual script title as well:)

Digital files are just what the body gives until they're layered working files or print files.

Mike
 

Jukka Vuorinen

New member
Thanks.

Thank you Ken. I just checked and DAM book is not currently available here, so I ordered it through local book store. So maybe in month I will get it.

You guys also made me realise I don't have to have unique names on files on disk, because I always (99.9% of time) use files through Lightroom. I just have to make up export naming system with which I can always trace back to certain image in LR. (maybe project_####, or something like that).

Thank you everyone. :)
 

Peter Krogh

New member
Jukka,
I hope it's okay to post this.
Since you're having trouble getting the book, you can order it directly from us at:

http://thedambook.com/offer

If you do so in the month of October, we'll also send you a code to get a full version of Expression Media 2 software for no additional charge (full retail price - $199). Where the page asks you for your organization, just write in Open Photography Forums.

Peter
 

Asher Kelman

OPF Owner/Editor-in-Chief
Jukka,
I hope it's okay to post this.
Since you're having trouble getting the book, you can order it directly from us at:

http://thedambook.com/offer

If you do so in the month of October, we'll also send you a code to get a full version of Expression Media 2 software for no additional charge (full retail price - $199). Where the page asks you for your organization, just write in Open Photography Forums.

Peter
Peter you are so welcome!

I'm thrilled to see your book bought by folk here!

BTW, could you address linking DAM to sales? I'd have expected add on modules by now!

Asher
 

Jukka Vuorinen

New member
I borrowed the DAM book for few days from one of my colleague, and read as much of it as I could. Great stuff. Just

After it, and one LR renaming tutorial video, and this discussion I thought that heck, no need to stress about it, just let LR handle filenaming. Now every image gets name JVU_XXXXXXX where XXXXXXX is number sequence which started from 0000001. Basically it's how many images I have imported since changing the naming convention. All is well. This has simplified my workflow.

But I just realized one possible negative aspect in this. Before the change when ever I encountered image in my harddrive (there are still some stray images there) I just could just rename it with my script and easily check have I already imported it. Because my script gave every image a name which was based on its EXIF data. Now I have get images capture date separately, and check manually does it exist in LR.

This made me think, would it be best (although slow and cumbersome) to rename images for their MD5 checksum. So every image would really have unique filename, which could always be formed from image data itself. This isn't very serious thinking, its intention is mostly just entertain myself.
 

Andrew Rodney

New member
Here’s my take on file names. First off, I know the date and time, its part of the metadata but I agree its useful to have this in the file name too. I just don’t like it at the beginning of the name. I’m awful at remembering specific dates but I’m pretty good at remembering stuff I’ve shot. I can’t recall the last time I was in Sydney but I remember I was there. So I like having the name and the date in the name (Sydney_05December07_066.dng). I want the first part of the name to be something I instantly recognize like the subject, then the date. Now I can see this was shot on December 5th, 2007, is the 66th image in the “group”.

I use Lightroom and place images into differing folders who’s names describe their contents (Santa Fe, Dogs, Photoshop World, Sydney etc). I also use nestled folders (Photoshop World>PSW2007, PSW2008 etc). Then I use Lightroom to automatically build file names using the Folder Name Template plus the date. Anything I place into a folder on import is used in the file name thanks to that token. If I pop 50 images into the Dogs folder, then 20 into the Santa Fe folder, I can select all in the “Previous Import” quick collection and type F2 and pick my naming template, all the images will automatically be named based on where they reside in a folder. IF I move an image from one folder to another in LR, its name updates based on the folder it resides within.

I like that I can scan images by viewing the folders in the finder, go into each folder and know what the image is based on its name and its date (SantaFe_10September28_113.dng, PMA2007_07March11_2185.dng). I also know if for some reason, a photo ended up in the wrong location (folder). I don’t want to totally depend on LR to know what an image content is, its date etc. For me its easier to scan a group of folders based on their subjects, then go into that folder and search by date if necessary. Been working well for me.
 
I have thought about using a checksum and rejected it: if you change only as much as one digit in your embedded meta data, the checksum will also be different - and you'll never be able to relate the new file to the original (at least not based on the file name).
 

Asher Kelman

OPF Owner/Editor-in-Chief
.................

I like that I can scan images by viewing the folders in the finder, go into each folder and know what the image is based on its name and its date (SantaFe_10September28_113.dng, PMA2007_07March11_2185.dng). I also know if for some reason, a photo ended up in the wrong location (folder). I don’t want to totally depend on LR to know what an image content is, its date etc. For me its easier to scan a group of folders based on their subjects, then go into that folder and search by date if necessary. Been working well for me.


If file ends up in the wrong location, it might get renamed incorrectly, but I guess it would never lose it's original file name, so you can still search for _113.dng, Can you also searchwith a wildcard, or _113.*?

Asher
 

Jukka Vuorinen

New member
I have thought about using a checksum and rejected it: if you change only as much as one digit in your embedded meta data, the checksum will also be different - and you'll never be able to relate the new file to the original (at least not based on the file name).

My original idea was to count the Checksum from actual raw data, not including metadata. That way checksum would not change if metadata is written to file. Actually, if it ever changes, most probable reason is data corruption.

Which reminds me, wouldn't DNG validation hash work well as checksum? If one uses DNG, it's there already in a file and it's counted from raw data only (AFAIK).
 

Jukka Vuorinen

New member
I borrowed the DAM book for few days from one of my colleague, and read as much of it as I could. Great stuff. Just After it, and one LR renaming tutorial video, and this discussion I thought that heck, no need to stress about it, just let LR handle filenaming. Now every image gets name JVU_XXXXXXX where XXXXXXX is number sequence which started from 0000001. Basically it's how many images I have imported since changing the naming convention. All is well. This has simplified my workflow.

(Not so) recent development.

Unfortunately because of LR bug (and a feature working agaist me) in filename sequencing I got duplicate filenames and I had to stop using this method. So I'm back using my own script and jvu_YYYYMMDD_HHMMSS_ACTUATIONS.ext naming scheme.

I rewrote my script in Perl and enhanced it so that it renames my images and copies the files from memory card to my external HD containing my images, and also backups them to my backup HD. Next step is probably that it embeds some IPTC (or XMP) metadata to files.

Anyway, my optimal goal is that if (when) i find a stray NEF image in from my HD I can rename it (if it's not already done) and get a filename which shows me where that image should be, so I can a easily check does it already exist there. With my current setup YYYYMMDD_HHMMSS part in my filenames partially offer me that functionality. But then there is the part to get unique filenames.

More later.
 

Cem_Usakligil

Well-known member
Hi All,

First of all, the link provided by Peter leads to a treasure trove. I certainly recommend that you read the very informative articles in the website dpbestflow.org even if you already have a good workflow for your digital photography. My hat goes off to Peter and to the ASMP for making this happen.
There is a very good outline here on how to use the checksums in the DNG for rock-solid data verification:

http://www.dpbestflow.org/data-validation/data-validation-overview

Re. the issues discussed in this thread, I too have wrestled with them for a long time. Originally I have read the 1st edition of Peters DAM book but I admit I did not follow it too closely at that stage. I set out to use file names according to the format:

/cam/yyyy/mm/yymmdd/yymmdd_hhmmss_######_cam.ext

The year and the time were taken from the image capture date/time of the exif.

The "######" was made up of the original 4 digit number given by the camera to the image (such as IMG_1234) and was preceded by the counter digit to indicate the 10000 ranges.

The 'cam' was a unique identifier for each camera I have owned, such as '5D' or '40D'.

This made sure that each picture name was unique and was sorted into directories per camera and date, which brought shoots together in a directory or a range of directories for multiple day shoots. Even if an image would "get lost" into another directory, I could always easily transport them back to where they belonged. Checking duplicates and completeness was reasonably easy. BTW, it goes without saying that the renaming and sorting into subdirectories was done during the ingestion process of the memory card (I've used ImageIngester Pro from early on have never looked back, certainly recommended). I have of course created backup copies of the ingested images and set them apart. I have never used DVDs or BDs as a backup medium. Instead I have backup up to NAS drives and also to on-site and off-site external hard disk drives.

When I worked on derivatives, I have added text suffixes to the original file name. For example, a raw file called "20091125_134559_01234_5D.cr2" would -when processed and turned into bw- be called "20091125_134559_01234_5D master bw.tif".

So far so good, but I have had a few practical issues with this scheme. The file names were too long, which made them difficult to remember and necessitated the enlarging of the file name column in various screens, causing screen real estate problems. I have reluctantly decided to change my naming scheme, but what would be a better one? It took a lot of reading/thinking and also a lot of soul searching. The latter, because I had become rather attached to my naming scheme and changing it to something shorter would possibly cause a "loss" of information and I wasn't sure I wanted that. Around the end of 2009, the 2nd edition of Peter's DAM book came out. I have bought and re-read it and to my pleasant surprise it was greatly improved and updated. This time around, I found myself agreeing much more with the recommendations in the book than before. Possibly, this was due to the experience base I have built up by trying to find my own solutions. Peter's suggested workflow and naming scheme is definitely one of the best possible solutions to this problem, so why should one rediscover the wheel, right?

The resulting new naming scheme is terrifyingly simple compared to the one before. It is:

/cam/yyyy/mm/yymmdd/A#####.ext

As you can see, I still use the directory structure of camera/year/date. This makes it very easy for me to find a certain picture of a certain shoot since I usually remember which camera it was taken with and when. However, this is optional. The idea behind the whole DAM workflow is that the DAM program one works with should help the user find what he is looking for independent of any structural directory structure. In my case, I use LR3 as my DAM engine. Since all the pictures have their exif and IPTC data cataloged in the LR3 database, I can search picture using dates, lenses, cameras, keywords, focal lengths, ISO values, what have you. I can use smart collections, static collections, etc. There is no need for me to hang on to this directory structure at all. I just keep it because it gives me a false sense of safety and is helpful when I am searching pictures in other applications than LR3.

'A" is a unique letter for each camera I own or have owned. I am not planning to have more than 36 cameras in total so this scheme should suffice for a very long time (i.e. 26 letters plus 10 numbers = 36).

The "######" is made up of the original 4 digit number given by the camera to the image (such as IMG_1234) and is preceded by the counter digit to indicate the 10000 ranges. I shall have a problem if I ever shoot more than 100,000 frames with a single camera, but I don't expect that to happen.

The derivatives have suffixes as before. For example, "f12345.cr2" becomes "f12345 master.tif", etc. Only master files have permanent derivative files. Transient files such as the ones I post here in OPF are regenerated from the master files whenever I need them. For posting on the web, I simply drop the suffixes and use "f12345.jpg" But if I have two or more versions of the same file to be shown on the web, I may rename them to "f12345_01.jpg", "f12345_02.jpg", etc.

Contrary to Peter, I don't include my initials in the file name since I don't normally deliver my files to 3rd parties for further processing or the like. As long as I am the sole processor of my files, I don't need to be reminded that they are mine, lol. Should I need to hand over some files to others, I can always add my initials as a suffix to the file name anyway.

In parallel to changing the naming scheme, I have also thought long and hard about the unique identifier which should link the original to any derivatives I create. I don't want to bore you with too much details but the final solution is very simple, elegant and practical. I use the the IPTC Title field (also called Object Name) for this purpose. When ingesting the files to my computer, I fill the title field with the file name (excluding the extension). For example, if the file name is "f12345.cr2", the title field is "f12345". For any derivatives created, I just retain this value of the title field (I never change it). Most image processing programs take care of this automatically, sometimes I need to synchronize the title field either manually or using scripts. Bottom line is, I can search my DAM database using the file's name and I can find all the derivatives regardless how they are called and in which directory they reside. BTW, the title field is one of the universally supported IPTC fields by almost all the image processing programs. It has been bullet proof against all the programs I have ever used (i.e. it does not get lost when the image is processed in some strange program).

To summarize, the simple and short file name makes it very easy to remember it and I can easily select a number range to process them together such as when I do tone mapping of the bracketed exposures. It saves screen real-estate and never causes a length problem (one should keep the total length of the file name and the directory path of the file less than 240 characters long). The title field as the linking pin (unique identifier) supplements this beautifully. I couldn't have been happier. This scheme works really well.

I hope that this helps you in evaluating your own needs.

Cheers,
 

Nill Toulme

New member
There's a lot to be said for unique filenames, especially if you offer images for sale. I have over 100k images on my website, and it's not terribly unusual for someone to order a print of one that's six or eight years old. They just give me the filename, and I can find it.

My images are event oriented, so that's how I name them... date, event, image number, filed away in respective event folders within subject matter folders by year.

Example - image #123 from the Big High School varsity girls' soccer match against Little HS on 27 Oct 2009 would probably be 091027-BHSvg-123 and live in folder \My Pictures\Soccer 2009\091027 BHSvg Little.

All of this (as well as image backup) is largely automated from the time I stick the card in the card reader, using Breeze Downloader Pro and Breezebrowser Pro.

Nill
 

Doug Kerr

Well-known member
Well, I'm only a snapshooter, not a real photographer, so we may be advised that there is nobody here that would be interested in my filenaming practices. Sarah who?

***********

CAMERA ORIGINAL FILES

The original files from the camera are stored on the hard drive under this scheme:

Filename

The files are stored with a filename of this form:

A12345.JPG​

where "A" represents a letter that identifies the source camera, "12345" represents the numeric part of the original filename, always built out to 5 digits, and of course "JPG" represents the filetype extension, whatever it is.

The files are all marked read only.

Directory

The files are stored in directories whose span is each 1000 potential file numbers. The structure is like this:

F 40D in
. . F 40D in 00nnn
. . F 40D in 02nnn
. . F 40D in 03nnn
etc.​

There is no effort made to identify the topic, event, location, date, etc. I will discuss the implications of this a bit later.

Mechanization

The files are all uploaded with the memory card in a reader, using Breeze Systems' Downloader Pro.

The program automatically creates the directories and steers the files to the proper one, reformats the filename as shown above, and sets the read only attribute. This is done under control of strings of tokens, Downloader Pro's substitute for a script language. It has highly evolved over the years, and lets me do everything necessary for this task.

The forming of the 5-digit new file number has to be done differently for different cameras, owing to their systems of numbering files and the structure of directories in the camera (e.g., it is different for an EOS 20D than an EOS 40D).

Really the process isn't quite fully automatic. I do have to use a different shortcut icon to trigger it for each camera, and its command line strings carry all the particular literals and formatting doctrine for that camera.

Downloader Pro will recognize different cameras and select different formatting strings. I have not yet gotten around to see if that can be used to do the whole job here, truly fully automatically.

PROCESSED FILES

Directories

Processed files are generally stored in directories for, and named to indicate, particular events, projects, subject areas, and so forth. The "plan" is highly "variable" (read, "erratic"), and I will not suggest a unifying scheme in that regard.

Filenames

The basic filenames begin with some tag to somewhat identify the subject, project, and the like, then (after an underline) the primary filename of the original camera file as stored on the hard drive.

A typical one would be:

Xmas_2010_F22763.jpg​

(Yes, the filetype extension is lowercased for files that have actually been processed - my image editor does that.)

There is no attempt to make this prefix precisely descriptive - the whole story may need to come from the directory trail.

In some case, the prefix has more description in it:

Xmas_2010_Carla_kitchen_F22654.jpg.
Xmas_2010_twins_in_bed_F22654.jpg.​

Note that no filenames have spaces in them - there are still too many places where this can cause something between an annoyance and a disaster.

If there are several deliverable files derived from the same original (different crops, etc), that is usually done this way:

Xmas_2010_F22763-01.jpg
Xmas_2010_F22763-02.jpg​

If there are variations for the same finished image (for example, a reduced resolution version for posting, or one with certain metadata suppressed) that is typically done something like this:

Xmas_2010_F22763-01R.jpg

Perhaps ones that carry two different schemes of annotation (one with all the people in the picture labeled, one with only the ones that are not on the lam) would have filenames something like this:

Xmas_2010_F22763-01A1.jpg
Xmas_2010_F22763-01A1.jpg​

DISCUSSION

Why no attempt to tag or segregate the camera original files by subject, project, date, etc.? This an be very helpful.

In my case, the reason is very practical: I just wouldn't do it. I go out and perhaps shoot two different events and a couple of interesting things I find along the way. I come home and upload 'em. Will I log what I did? No. Would I categorize and tag the files? No. I just upload 'em and go on about my business.

Suppose I want to find the original behind some delivered processed image to make a new version. Well, the deliverable has the filename of the camera original in it.

Suppose I want to look through other frames from the same event ("but did you get a shot of Janie?"). I start with the filename embedded in a deliverable for the same event (if any had been processed) and then use BreezeBrowser to browse through the camera original files near it in in number.

Supposed none of them had been processed? If I know the date of the event, I just search through the camera originals by file date.

Suppose the challenge is, "remember that time we saw the three-legged cow alongside the road and you shot it. Can we find that?"

Only by a lot of browsing.

Would it be nice if I somehow added keywords in a database. Sure, but I wouldn't do it.

Suppose I did that, a very tedious process every day, and had this one tagged with "cow", "three legged", "cornfield", "Summit County", "rainy day", "right side of road", etc.

Now the challenge is, "remember that time we saw some farm animal that was funny somehow on a farm with a purple tractor in front of the barn, and you shot the scene. Can we find it?"

Only by a lot of browsing.

Best regards,

Doug
 
Top