Here's how I did it:

I created both the thumbnail and the screen-sized compressed image using ImageMagick from the Perl script. The original, higher fidelity large size, image is on the server.

Every image is assigned a random code number. Not sequencial numbers, but random, for two reasons: so they hash nicely, and so people can't guess at numbers for pictures they were not shown in the album.

Anyway, it associates a fully qualified file name of the original image with the code number.

Now, when an image is needed of some size and quality (thumbnail or screen-sized), it forms a filename by combining the code number with option values.

If that file name exists in the image cache directory, serve it up! If it doesn't exist, generate it first using ImageMagick, then serve it up. When cache gets too large (e.g. 1GB) oldest files are deleted (could be better).

The file system is part of my database! As for copying/moving, it's a automatically-generated cache, so big deal, just delete it. For moving or renaming source images, the primary input to the system is actually the directory of full-sized images, and it scans that for available files. It will automatically notice changes when an album is displayed.

Now, that's a complex system with security and billing and everything, and selectable resolutions and quality and monitor calibration. It was a bit to bite off, so I also made a simpler (really simple) server that I could use without such a large development effort. It fills my needs of delivering immediate results to models who just had portfolio shots taken. There is one working directory that the script uses for its stuff. I put a configuration file, e.g. foobar123.ini, into that directory and include lines in it pointing at the source directory of full-size images (it can reach my work area via the network, where her files actually live), the desired resolution and quality settings, how many "up" to list, album title, etc. With stock settings, a simple perl script generates this ini file automatically given the target directory name.

The name, foobar123 in this case, is actually randomly chosen, so simply knowing it amounts to a password. Put that "personal password" in on the main page, and it reads the ini file of that name, and also looks in a subdirectory of the same name for its image files. When one album page's HTML is generated, it makes sure that all the thumbnails and screen images exist, creating them if needed. So the first time the page is served it is generated, and the IMG files and links are all normal static files, not scripts to serve them up. All the generated files for that album are in one place in a subdir, so it is easily deleted when I'm done with it. There is no database: static settings only in the .ini, and files in a subdirectory make up the whole system.

—John