Return to Digital Photography Articles
First step, make sure you have a strategy for naming your photos effectively.
The two main strategies that are generally used are: placing files from the same "import batch" in a single folder or placing files from the same date in a single folder. The Microsoft Scanner and Camera Wizard uses the first method. I have found that the first strategy (files are organized per import batch) to be quite limiting. It is often the case that one takes photos across multiple days, all onto a single memory card before downloading. This will cause multiple days' or events' worth of photos to be placed in the same folder. This sort of organization is rarely useful, and makes the task of searching for photos from a particular day more difficult. A goal of the folder hierarchy is to ensure that: there is a manageable number of photos in each folder, and that there is a manageable number of subfolders in each parent folder.
If one is often taking a large number of photos in a single day, then it makes sense to have the lowest level folder named for a year-month-day. If only a few photos are taken per month, then a lowest level folder named for year-month might make more sense.
At one level up in the hierarchy, one again has to re-evaluate the typical usage rates. If one has photos for nearly every day of the year, then it would make sense to create folders for each month (eg. year-month). Again, this would probably be overkill for those who don't shoot that often, where this extra level (per-month) would end up creating a lot of sparsely-populated folders. It is best to look at an example, this one being the method I use as my folder strategy:
Examples of Digital Photo Folder Organization
2004/
2004-01-10/ files...
2004-01-21/ files...
...
2004-12-13/ files...
2004-12-24/ files...
2004-12-31/ files...
2003/
...
2002/
...
0000/
...
|
| Folder hierarchy for small collections |
As I shoot every few days, I have considered changing my folder hierarchy to add another level, but I have decided against doing this. I do not find it problematic having a hundred folders within each year folder.
2004/
2004-01/
2004-01-10/
2004-01-21/
2004-01-23/
...
2004-../
2004-12/
2004-12-13/
...
2004-12-24/
2004-12-31/
|
| Folder hierarchy for large collections |
The following table shows an example of my completed hierarchy, including all types of files and the folder I use.
E:\
Pictures\
0000\ Unknown Year
0000-r0164\ Unknown Year, Scan from Print Roll 0164
00000000_r0164_40-s.jpg Known roll, unknown print #, resized
00000000_r0164_40.jpg Known roll, unknown print #, original
0000-r0166\
0000-r4795\
...
0000-r9999\
unknown\ Unknown Year, unknown roll, TO BE LOCATED
1999\
2000\
2001\
2001-01-10\
20010110_r3201_13.bmp Scanned print, known year, roll & photo
20010110_r3201_14.jpg
20010110_r3201_15.jpg
20010110_r3201_15-e.jpg
2002\
2003\
2004\
2004-01-01\
20040101_0556.JPG
20040101_0557.JPG
...
2004-01-04\
20040102_0745.JPG
...
|
| Example of complete hierarchy |
Where to store edited versions of photos?
There are several common strategies for dealing with multiple versions of the same digital photo in your folder hierarchy. This includes edited versions (perhaps saved as a Photoshop PSD file or another file format) and resized images. Three methodologies are explored below:
- Edited versions in same directory as original
- Edited versions in subdirectory of original
- Edited versions in same intermediate directory hierarchy as original, but with different root directory
Probably the most common method is #1 as it is the one that is naturally followed by default (ie. not requiring any additional directories to be created). It is also the methodology that I currently follow, although I have been considering the alternatives as I have talked to a number of other photographers who have used #2 or #3 instead.
Examples of strategies for edited versions
An example of each of the three strategies are shown below. Note the slight differences in the folder hierarchy.
E:\
Pictures\
2004\
2004-01-01\
20040101_0556.JPG
20040101_0557.JPG
20040101_0557-e.JPG
20040101_0558.JPG
20040101_0558-e.JPG
2004-01-02\
20040102_0711.JPG
20040102_0711-e.JPG |
| Example of edited versions in same directory |
The next example shows a methodology whereby the edited versions are in a subdirectory of the original photos.
E:\
Pictures\
2004\
2004-01-01\
20040101_0556.JPG
20040101_0557.JPG
20040101_0558.JPG
edit\
20040101_0557-e.JPG
20040101_0558-e.JPG
2004-01-02\
20040102_0711.JPG
edit\
20040102_0711-e.JPG |
| Example of edited versions in subdirectory |
The final example shows a structure that places the edited versions in the same hierarchy as the original photo, but with a different root:
E:\
Pictures\
2004\
2004-01-01\
20040101_0556.JPG
20040101_0557.JPG
20040101_0558.JPG
2004-01-02\
20040102_0711.JPG
Edit\
2004\
2004-01-01\
20040101_0557-e.JPG
20040101_0558-e.JPG
2004-01-02\
20040102_0711-e.JPG |
| Example of edited versions in same hierarchy, different root |
Differences between strategies
As for the differences between strategies, it all comes down to the degree of protection / isolation of the originals versus the edited versions, and how other tools in the workflow treat the directory hierarchy. Most image catalog programs rely on a centralized database to access the photos, and so the actual directory hierarchy doesn't generally come into play. However, when one wants to script various operations (such as adding an "Edit" state tag to all photos that have been edited), being able to associate the originals with the edited versions becomes important. For such scripting scenarios, the decision on which strategy to employ depends on the flexibility of the scripting language in dealing with directory pathnames.
Impact on Applications and Scripts
The directory strategy chosen has a potential impact on the photo catalog applications or scripts. It is important to ensure how the tool uses the directory hierarchy and if one strategy is easier to handle than another. It should be noted that the Manage Versions script I wrote for IMatch has a configuration option that allows any of these three strategies to be used.
Reader's Comments:
Please leave your comments or suggestions below!Also, have you considered a hierarchy like this: yearroll numberdatesfiles.jpg:
e.g:
1999 r8099 19990101_r8099 199990101_r8099_01.jpg 199990101_r8099_02.jpg 19990102_r8099 199990102_r8099_03.jpg 199990102_r8099_04.jpgDo you see any drawbacks with this?Thanks.
Your strategy should be fine, although I would tend to find it a bit more cumbersome and not well suited to how I search for a given photo.
I have set Page Style to No Style in Firefox to achieve a white background. But that's a bothersome kludge.
Again, I really appreciate your materials here.
DRA
then c:/photos/2007/working/20070106_0001.TIF or PSD
finally c:/photos/2007/finished/20070106_0001.JPG
or something like that...I can't remember exactly but I'm still experimenting myself (and currently writing a heirarchy up on paper before going through my entire hard drive).
I just wanted to add my 2 cents.
I add a 1 digit # to the scheme in the end, to handle version.
example: 20090321_140139_23.0.jpg
The last .0, tells me its version 0, meaning its the unedited version.
If its the edited version, I'd use the 1-9 numbers there.
I don't edit photos too much, so 1 digit is sufficient, in fact that value doesn't exceed 3 in my collection.
As an alternative to this strategy, one could skip the .0 all together and use that digit (1 thro 9), only for edited imgaes.
So, if a photo has a .?.jpg then its edited, otherwise its unedited.
YYYY-MM Event Orig PSD Adjusted Sharpen FinalOrig = original images. Right off the camera. Only thing that happens here is chunking the junk.
A Photoshop script run on the original makes a photoshop file of each one.
Start it, and go away for an hour.
First step is crop to get rid of the extra pixels. Makes everything later faster.
Next step is non-destructive adjustment layers.
Final step is to sharpen.
Single PS script to output into the final form.
On everyday work I also deal with thousands of folders. Basically I work with the strategies found here. In my opinion it can also be improved with the help of tools like Folder Scout (http://www.folderscout.com). It gives you instant access on any folder organization scheme, no matter how deep or complex you hierarchy is. Once you start to use it, you can't live without it !
Calvin, Folder Scout is a 'Try before Buy' software. If you find it useful after 30 days trial, I will very pleased sending you a registered copy for free.
Regards,
What about using the stategy you speak of but scaling back by just using the year "2006" as the folder and putting all 2006 pics in that folder?
If that wouldn't work what about year then month?
I am afraid of loosing the category and data that I am spending so much time on in the software. once that is gone I won't be able to remember some of the photos.
- How to deal with multiple overlapping categories
- How to deal with category hierarchy
- How to keep a consistent set of names for these categories
- How to update category names over time
The biggest problem is certainly the first one. Let's assume you have a category for Birthday and another one for Pets. If you have a fantastic photo of your dog in the set of photos from a relative's birthday, which folder are you going to use?Using a wide set of category names in either the directory names or photo filenames will get most people into trouble very quickly! The only times that it tends to work is if you want to add a client job's name (for example), or you have a very careful, methodical use of a limited set of category names (a controlled vocabularly).
I'd really caution against this type of approach -- as you can end up making a lot of work for yourself and it is precisely the reason that photo catalog organizers are so popular.
That said, the hard part for most people in adopting a filename/folder name strategy that doesn't include any keywords is that they feel uncomfortable about having to rely on some external catalog software program to retain the category information. So long as you choose any reasonable catalog program that supports export functionality and/or writing of keywords into the files / IPTC, then you should be fine in making this transition.
A good way to think about it is the following: for every photo in your database, there are really two parts -- the file itself and the entry in the database. Generally, the entry in the database / catalog is the part that stores the categories, along with the full pathname to the file itself on the disk. When you open up the photo from the database program, it will locate the entry in the database, read the full pathname and then open up the file itself.
If you move a file from within the catalog program, then not only does it move the file on the disk, but it updates the link in the database entry to point to the new location.
When you move a file (that is in the catalog / database) but without the help of the catalog program (e.g. using Windows XP's Explorer, dragging and dropping a file), then you are only moving the file on the disk. The photo database still thinks that the photo is located at the old location, so when you try to view or perform other functions inside the catalog program it will say that the file is missing or offline.
At that point, you can usually tell it how to find the new location for the file on the disk (known as relocation). Some catalog programs are better at doing this than others. Some will even detect where the file moved to, but this is only usually possible if your catalog program was open at the time during the move. When you move many files at once, this will become a much bigger issue -- if the catalog program is good at relocating files, then you may need to only locate the first moved file and it will be smart about relocating the rest. Other programs will ask you to find each and every moved file!
As an aside, one nice feature that you'll find in most catalog programs is the ability to write the keywords into the file. Now all of the keywords will be kept inside the actual photo file (inside the EXIF/IPTC metadata). So, if you move the files around, it doesn't matter if the catalog program can't find the photos anymore (the links will point to the old location)... that's because you can tell the program to re-import all of the photo files from the new location and then import all of the keywords that are stored within the files (usually called IPTC Import).
Most serious photographers will eventually get used to writing the keywords into the files themselves (using IPTC or XMP) as this allows you to preserve and share your keywording information with others even if your catalog database were corrupted someday or lost.
There is another folder strategy that can make sense for recreational photographers -- e.g. the masses just taking vacation photos and the like -- and that is to organize by theme or event at the lowest level, still contained inside a chronological hierarchy. Basically after importing you group all pictures that are related, say, Jill's wedding, or Jack's soccer game, or Hike up the Sioux trail, and name the enclosing folders based on that. This can make it easier for users to find particular pictures on their hard drive without necessarily relying on the Catalog application. Here is an example from my own folder heirarchy, modeled based on my taking a 2-5 'rolls' of film a month...
Pictures 2004 2004 1_NewYearsDay 20040101_NewYearsDay_01.jpg 20040101_NewYearsDay_02.jpg ... 2004 1_Snowboarding-at-Hood 20040109_Snowboarding_01.jpg 20040109_Snowboarding_02.jpg 20040109_Snowboarding_03.jpg ... 2004 1_Raquels-Bday 2004 2_Skiing-at-Vail ... 2004General 20040503_JimsNewCar_1.jpg and so on...I name both the photo and the enclosing folder with the theme of the the particular shoot that relates the photos. Note that if I have a few photos here and there that are just one-offs, or not part of a particular event or something, I just dump them in that year's General folder. The photo still gets named with a date and a short name, as shown by the example 20040503_JimsNewCar_1.jpg above. In all cases I strive to keep the theme name as short as possible, limiting to around 15 characters, keeping the entire photo name below 30 characters with data and sequence number. That's enough to know exactly where in my folders an accidentally separated photo should go... and it usually provides a good tidbit of info for others when I email or otherwise share photos...
Anyway, just another take on naming and folder strategies.
Regards, Jim
P.S. I also usually use that same theme name as a keyword on the INSIDE of my Cataloger application, to tag that same set of images as a collection. And of course write that same information into the file's IPTC header.