and thank you so much for making web galleries so easy within LR.

I’m using Your Highslide Gallerie and lately i’m starting too make use of its great Client Proofing feature. Now I am thinking would it be possible to combine the Download feature with the selections?
So that the Client will select the pictures and instead of generating an email with the selection, a nice PHP script will pack the selectet Pictures to a Zip file and provide it for Download.

Since i have no idea of programming at all this would be a cool add on feature for the future i think.

keep up your great work!
cheers
hans

I agree with you, that filenames are not the place to store metadata, that’s what the catalog is for. I think (IMHO) these rules make sense to apply:

1. In order to identify the file without any ambiguity, the filename must be unique throughout your entire life. There must be no chance of a diffenernt file ever getting the same filename again.
2. The filename must contain only information, which can be automatically derived from the file. This is important to prevent user interaction during the process of importing files, especially if you want to import from different directories on different drives in one single batch run.
3. If you see the filename of one single file, you should have the ability to know (or derive) without any doubt the exact location of this file inside your folder structure. This helps a lot if you come across a file which isn’t where you expect it. You can immediately see if it’s a duplicate of the original file or if you accidently moved the original file.
4. The process of importing should be (as everything else) non-destructive. This means that the original filename (at least the number) should be reconstructable. This helps a lot, if you discover some files on old memory cards or in old backups. Then you can decide very fast if you have these files in your catalog, without even looking at their content. Or you might have made some comments on a paper for some special filenumbers during the shoot and you find that paper only after you imported the files.

The filename scheme I’m using satisfies all these rules. My filenames are like this:
(Initials of photographer)_(Date)_(Camera)_(original filenumber).cr2
AG_20100620_5DII_04855.cr2
All files are stored in a folder structure like this: Directory for photos/2010/20100620/AG_20100620_5DII_04855.cr2

My initials are in the filename, because sometimes I share my files with other photograpers and when we copy our files back and forth on our laptops, it must be immediately clear, which picture comes from whom.

Please don’t take this personally, but I’d like to point out, why the filename scheme you suggested is not a good idea (at least not for me, maybe it works good for you). You are suggesting: spain_church_456
At the same time you say, there should be no metadata in the filename. But spain_church is exactly that, metadata! And there are other drawbacks: Lets say you come home with 10 memorycards of 10 shootings on 10 different dates ond locations in spain. During the import process you would have to come up with 10 different names to describe these files. But this is work which should be done after the import when you start to categorize your files!
Maybe in 2 years you get back to the same location again and shoot some more photos. If you choose the same filenames again, the files are not unique anymore. You might not even notice that if you keep the files in different directories, but there’s still an ambiquity.

Of course I realize that this is a little over the top for most users, but just imagine that in the future you will produce a massive load of photos. Then you would have to come up with a system like that sooner or later. And instead of changing all you filenames at some point in the future, why not make it right from the start?

File names are not the place to store metadata. That’s what the metadata is for.

File names should be something like “emily_123″ or “spain_church_456″. I don’t even change mine from the number assigned to them from my camera.

Instead of coming up with some clever yet difficult work-around, use the tools and the data structures as they were intended. Life is much easier that way.