How do you manage images with duplicate file names?
I don't! :) Instead, I avoid having images with duplicate filenames by renaming them before import. That's it!
[Actually, I use hard links, but it amounts to the same thing.]
That's really my whole answer, in its essence. You're welcome to read on for more details on how I, personally, achieve that, if you like. If my answer gets confusing, though, just focus on the above concept -- there are lots of other ways to achieve the same basic concept.
Note: The rest of this answer is kind of UNIX-ish and geeky in some of its nomenclature. The concepts are general, though, and surely this sort of thing could be done elsewhere. If anyone has suggestions on how to improve the way I've written this answer, I'm happy to hear them. I'm also writing this when tired, and I tend to be verbose, so... hopefully this will all make sense, and if not, please let me know, and I'll do my best to clarify in an edit.
In particular, I have a script that I run called import_card
, which asks for a name for the shoot/session/whatever, and then does the following:
Make sure I'm in an appropriate directory for importing images into. (This could be done a number of ways, but the way I do it is just to make sure that there's already a directory matching the current year and month, as YYYY/MM.)
Look for one or more memory card(s) that are currently attached to the computer.
Scan the data on each card (looking at EXIF data), one-at-a-time, to figure out which camera the images were recorded from (by serial number), and what the most recent date was of an image within the card (if there are multiple dates, I go with the most recent). (Note: there could be multiple cameras on a single card; I mostly try not to run into that case, but it's handled well if I do.)
Copy the data (exactly) from my card(s) into a folder like:
./YYYY/MM/YYYYMMDD-cameraID-the_name_I_entered.in
Where cameraID
is a short name (e.g. "30d" or "g9", or sometimes something longer to indicate a borrowed camera) that I've assigned to an individual camera (or multiple such IDs if the card was shot with multiple cameras) based on the serial number of the camera(s). (For cases where the EXIF data doesn't include a serial number, I have some other heuristics I use to guess, which mostly works well for the limited number of cameras I use, but could break down for some). This folder might have filenames within it like:
DCIM/123CANON/_MG_4567.CR2
(I primarily shoot Canon, but this could be done with other cameras, too, and my script handles a few different types of canon and at least one other brand of camera, as well.)
Once that's done, do the renaming (really hard linking) using (and this is the key to this whole thing) the name of the DCIM subdirectories as part of the ID. So, a new directory gets created like YYYY/MM/YYYYMMDD-cameraID-the_name_I_entered
(without .in
) which takes the 123
in 123CANON
and the 4567
in _MG_4567.CR2
, combined also with a (different) short(er) prefix identifying the camera (usually one-letter for my own cameras, and several letters for cameras I've borrowed) -- again, based on the serial number of the camera used for each image (so if I've shot a card on multiple cameras, the individual files will get different prefixes, whether or not the numbering scheme is different between the cameras), creating files like (assuming a prefix of "e", which is my current main camera, but it could be anything):
e123-4567.CR2
I then import the directory created in the previous step (i.e. not the one with ".in" in its name) as a new project into Aperture or Lightroom (I've used both at different times -- they each have their advantages). From there, the "Master filename" and "Version number" (Aperture terminology, I forget what Lightroom calls the same concepts) has the unique-to-my-entire-library string e123-4567
in it. When I then export images for whatever purpose, I include this in the name of the exported file, along with (sometimes) my name as a prefix (for images I'll be giving directly to others) and (frequently, especially for e.g. flickr uploads) some sort of descriptive title (matching the flickr title, so I can easily tie them together) of the image, and/or of the "version" of it, if I have different edits (the latter being something I store in the "version name" within Aperture).
Between all of the above, I get the following benefits:
I have an archive of the exact data from the card. If I ever want to, I could put that data back onto a card, and the camera would be able to understand it as though it had never been removed.
The images I import have a pretty-much-guaranteed unique number.
(The caveat: If I ever roll past 999CANON for folder names, I'll have trouble -- and I am up to about 985CANON, but that's mostly because I used to share a card back and forth between a Canon 10D, which only put 100 images in each such folder, and a 30D, which puts basically 10,000, but took over numbering from where the 10D left off, and then the 10D would do silly things with that. I've been at 985 for a while, and don't expect to exceed 999 before having a new camera body, which I will be careful not to pollute the numbering on, and thus will start with, I think, 100CANON. If I ever do hit up against the 999 limit, though, I can just change the prefix for that camera, and all will be well.)
The unique number is relatively short, so my filenames aren't too huge, usually. (The directory (and therefore project) names are sometimes annoyingly long, alas, but I like having that info handy, so I deal with it.)
I don't know why Aperture and Lightroom and such don't allow putting data like this into the filename. Especially the part of taking the number from the folder name in the DCIM directory. Alas, they don't. So far, anyway. :) I know Lightroom has some rules for renaming things during import, and you could probably achieve an alternate version of this idea using that (based on date, most likely), but it didn't have any way to extract the DCIM folder ID, last I looked.
Anyway, I hope this is somehow helpful to folks. My script is currently written in a way that's highly customized to my own needs, but I could probably be convinced to clean it up and release it as an open-source thing, if there's enough demand. Or, if you're good with ruby, perl, python, or the like, you could write your own version.
Or you could bug Apple and Adobe to build something like this in to their products. :)