The Day I Stopped Doing It the Slow Way

It was a Saturday in October, two years into running my own post-production consultancy. A mid-size e-commerce client had sent over 500 product images, all shot on white, all needing the same treatment: levels correction, a sharpening pass, resize to 2000x2000 pixels at 72 DPI, save as JPEG at quality 8, export to a delivery folder. Straightforward work. The kind of thing that feels fast until you’re doing it for the four hundredth time and your wrist has started to ache.

I spent that Saturday building a system instead of doing the job manually. By Sunday afternoon, I ran the batch. By Monday morning, the client had their files. I billed for the work, not the hours, and that gap between the two is where this whole thing gets interesting.

What Photoshop Is Actually Doing When You Batch

Most people treat Photoshop’s batch function like a convenience feature, something you use occasionally when you have “a lot” of files. But understanding what’s happening under the hood changes how you build for it.

When you run a batch through File > Automate > Batch, Photoshop is executing a recorded Action against each file in a source folder, opening each image, running every step in sequence, then either saving in place or routing to a destination folder. The key word is “recorded.” Every step you take while recording an Action gets logged as an absolute instruction. If you record a canvas resize at 2000x2000, that number is hard-coded. If you record a Levels adjustment by dragging sliders, Photoshop saves those exact input and output values, not your intention.

This matters because it tells you exactly where things break. A batch will fail silently, or produce garbage output, when your source files have inconsistent color profiles, mixed bit depths (8-bit versus 16-bit), or varying canvas orientations and your Action doesn’t account for any of that. The Action isn’t smart. It’s a tape recording, and you have to engineer around its limitations before you record a single step.

Building an Action That Actually Survives the Real World

Before I record anything, I audit the source files. I use Adobe Bridge with the Filter panel to sort by color profile and flag anything not in sRGB. For product photography destined for web, I need everything in sRGB at 8-bit before the Action touches it. I handle profile conversions as a separate batch step first, using Edit > Convert to Profile with the Photoshop batch function, before the main processing batch ever runs. Two batches, two folders, zero surprises.

For the Action itself, I build it against a representative worst-case file. If my client’s images range from 3000 to 6000 pixels on the long edge, I record against the 6000-pixel file. I set Image Size to constrain proportions and target the long edge at 2000 pixels using the “Fit Image” command under File > Automate rather than Image > Image Size directly. Fit Image is underused. It resizes without distortion regardless of orientation, which means one Action handles both landscape and portrait crops without branching logic.

My sharpening step uses Unsharp Mask at 120%, 0.5 pixel radius, 3 threshold. That’s tuned for product photography at web resolution and applies consistently regardless of what the image was before. For the save step, I always use “Save As” with a defined destination folder inside the batch dialog rather than saving in place. Saving in place is a great way to accidentally overwrite original files at 3 AM when you’re tired.

The Spreadsheet I’m Maybe a Little Too Proud Of

I keep a running log of every Action I’ve built and every batch I’ve run, tracked against time saved. Right now I’m sitting at over 2,400 hours recovered since I started doing this seriously. That number is conservative because I only log confirmed job time, not the speculative overhead of what manual processing would have cost me.

The October batch I mentioned, 500 images, took 47 minutes to run unattended. I know because the spreadsheet says so. Manual processing at roughly 90 seconds per image would have been 12.5 hours of focused, repetitive clicking. Those 12 hours went somewhere more useful. Some of it went to sleep. Some of it went to actually thinking about the next job.

What I want to be honest about is that the build time matters. That Saturday I spent engineering the system was probably six hours of actual work. The payoff came because that same Action, with minor tweaks, has run on dozens of similar product jobs since. If you’re building a batch system for a one-off job you’ll never see again, the math might not pencil out. The leverage comes from repeatability.

When the Batch Breaks (and It Will Break)

Batch automation fails in predictable ways once you know what to look for. The three most common failure points I see are: Actions recorded with “Allow Tool Recording” off (meaning brush strokes and some adjustments don’t capture), files that trigger a dialog box mid-batch and halt the whole queue, and destination folders that fill up a drive and cause Photoshop to error out silently.

For dialog boxes, the fix is checking “Suppress File Open Options Dialogs” and “Suppress Color Profile Warnings” in the Batch dialog before you run. For drive space, I keep a minimum of 50 GB free on my working drive before any large batch. For the recording gaps, I test every new Action on three different sample files manually before it ever goes into a batch. Three files, three different edge cases. If it passes that, I trust it.

The single most valuable thing I can tell you about batch automation is this: the system is only as reliable as the time you spend breaking it before your client’s files do.