It does sound like our batch images processor is the right fit for you.

It works like this:

Does this sound like the solution for you?

Yes, it does. 

I need to add a nice bulleted list of features to our write up.

Here's how it works:

Based on the file naming convention SKU.jpg -- for the largest image -- the processor runs through the batch of images you've uploaded to a temporary folder and resizes the detail, general and thumbnail images according to the settings you've set (complete with lossy control if the server is running ASPJpeg), stores each image in a sub-directory of the /pc/catalog/ directory (i.e. /detail/, /general/, /thumb/) and then uses the file name to find the product record in the database and updates the file location fields. It them deletes all of the temporary files.

So, you don't even need to include that info on your spreadsheet imports.

It even supports alternate images/additional product views (simply use the file naming convention SKU-alt1.jpg, SKU-alt2.jpg, etc) and sub-product images for Apparel add-on stores (generating just one "color/pattern" image for each size option group).

It also includes two file clean-up features: when you delete/remove a product from the category, it deletes the product images from the server; or there's an orphaned images feature that finds all images for which there is no current product SKU and moves them to a temporary folder you can download for review.

Depending on the size of the original images uploaded, it can crank through hundreds of images at a time.

It only has one feature limitation that has come up (if one doesn't count naming product images by their SKU, which is generally a best practice anyways): If one uses the same image redundantly for various SKU's, runs into the core issue of using the file names to find products in the database (or, on the other side if the delete images option were installed, it would delete the image shared by multiple products if one where deleted). This is easily worked about, though.

Hope that all makes sense. I certainly see that our description is due for an overhaul/update.

Yes, the data must exist in the database before an image can be matched to it.

However, if necessary, the orphaned image clean-up tool could easily be adapted to find images for which there are product record matches, but currently don't have images assigned to them. It would be more difficult to handle alternate/additional product view and apparel sub-product images this way, though.