If you retouch product images for a living, you have run Image Processor on a Friday afternoon. A few hundred PSDs in a folder, three rendition sizes, a coffee, and the hope that Photoshop does not crash before the queue finishes. It usually does the job. Until the queue is two thousand files, the deadline is Monday morning, and the studio has three retouchers all waiting on the same machine.
Image Processor Pro is the upgraded version most retouchers reach for. It is genuinely useful, and for a long time it was the cleanest batch tool in Photoshop. It is also a script running inside one Photoshop session, which is the limit you keep hitting once volume grows. This article walks through what IP and IPP actually do, where they stop scaling, and what production-grade batch retouching looks like beyond them.
TL;DR
- Image Processor ships with Photoshop at
File > Scripts > Image Processor. It saves the open image (or a folder of files) into JPG, PSD, and TIFF in one pass, with optional resizing and an action. - Image Processor Pro is Russell Brown's enhanced version - same idea, but multiple output presets per run, custom suffixes, and copy-metadata options.
- Both are sequential JSX scripts inside a single Photoshop instance. They choke on large queues, can't render different actions per rendition, and don't survive a Photoshop crash mid-batch.
- The modern stack at studio scale is layered: droplets and Bridge for ad-hoc runs, UXP plug-ins with BatchPlay for scripted production work, ImageMagick for headless conversion, and Adobe's Photoshop API for cloud-side rendering.
- IP/IPP belong on the retoucher's desk for finishing passes. Bulk export, naming, and channel-specific renditions belong upstream of Photoshop, in a managed pipeline.
What Image Processor and Image Processor Pro actually do
Image Processor is a built-in JSX script. You find it under File > Scripts > Image Processor, or as a file at Presets/Scripts/Image Processor.jsx inside the Photoshop install directory. Bridge ships the same script under Tools > Photoshop > Image Processor, which lets you select files in Bridge and hand them off to Photoshop in one click.
The script does four things in one pass: open each source file, optionally run a Photoshop action, optionally resize to fit a width × height, and save out to JPG, PSD, and TIFF in any combination. Output goes either into the source folder or a folder you pick, and each format gets its own subfolder (JPEG/, PSD/, TIFF/). For most studios, the JPEG/quality slider plus "Convert profile to sRGB" is the entire e-commerce export workflow.
Image Processor Pro is the upgraded version maintained by Russell Brown and distributed through Adobe's Dr. Brown's Services panel. Same core idea, but the dialog is rebuilt for retouchers who need more than one output preset per run. The main upgrades worth knowing:
- Multiple destination presets in a single run - for example, a 2000 px sRGB JPG, a 1000 px square crop, and a full-size AdobeRGB TIFF in one pass.
- Custom file-naming with a prefix, suffix, sequence number, and the original document name as tokens.
- Per-preset action choice - IPP can run a different action for each output size.
- Optional metadata copy, optional flatten, optional
Save for Webquality.
That last one is the real reason retouchers like IPP. In plain Image Processor, every output runs through the same action; in IPP, the 2000 px PDP render can use a "sharpen for web" action while the archive TIFF skips it. That single feature covers most of the "I need different processing per channel" need that comes up in a packshot studio.
Where Image Processor Pro starts to choke
For a single retoucher with a hundred files, IPP is fine. The problems show up at studio scale, and they are not fixable inside the script.
It is sequential and single-threaded. Photoshop opens one file, runs the actions, saves the renditions, closes, and moves to the next. Modern machines have 16 cores and the script uses one. A 2,000-file queue at 4 seconds per file is over two hours, and the retoucher's Photoshop is locked the entire time.
It runs in the same Photoshop instance the retoucher is using. Either you take the workstation offline for the batch, or you set up a second machine as the "export box." Both options are common, neither is great. The export box quietly becomes a piece of infrastructure with no monitoring, no logging, and one person who knows how it is configured.
It does not survive failure cleanly. If Photoshop hits a corrupt PSD halfway through and crashes, IPP loses the queue. There is no resume. You sort the source folder by modification date, find where it stopped, and re-run the rest. On a Friday at 18:00 this is not where retouchers want to be.
It has no awareness of the rest of the pipeline. The script writes files to a folder. Nothing tells the DAM, nothing notifies the client, nothing logs the export against a job. That work has to live somewhere else, and in most studios "somewhere else" is the retoucher manually copying files into a delivery folder.
Modern batch alternatives at studio scale
Beyond IPP, Photoshop and the surrounding tooling give you four production patterns. Most studios end up using a combination, not one.
Droplets. File > Automate > Create Droplet saves an action as a small executable. Drop a folder of PSDs onto the droplet and Photoshop runs the action on each. Droplets are excellent for one specific job - the same action, the same output - and a retoucher can prepare and share them without writing code. They have the same single-Photoshop-instance limit as IPP.
Bridge batch and Image Processor. Tools > Photoshop > Batch in Bridge is the same engine but with better source-selection. You select files in Bridge - across folders, with metadata filters - and Bridge pushes them to Photoshop. Useful when "the files I want to render" is not a tidy folder.
UXP plug-ins with BatchPlay. Adobe's modern scripting platform replaces the older ExtendScript runtime. UXP plug-ins use the BatchPlay API to drive Photoshop programmatically, with proper async handling, manifest-based packaging, and a real debugger. If your studio has a half-rotten .jsx script that nobody fully trusts, UXP is where it should live next. The Photoshop UXP and BatchPlay reference is on developer.adobe.com.
ImageMagick on the command line. For renditions that do not need Photoshop's layer logic - sRGB conversion, resize, square-crop with padding, JPEG quality, format conversion - ImageMagick is faster, scriptable, and headless. A single magick mogrify invocation can process thousands of files across all CPU cores in the time IPP needs to open Photoshop.
magick mogrify -path out/ -resize 2000x2000 -profile sRGB.icc \
-format jpg -quality 85 *.tif
Adobe's Photoshop API. For studios that have outgrown the desktop entirely, Adobe sells a cloud-side Photoshop API as part of Firefly Services. You POST a PSD reference and an edit description (smart-object replacement, text edits, rendition export), and Adobe renders server-side. This is the right answer when the bottleneck is "we cannot run enough Photoshops in parallel," and the wrong answer when the work is genuinely interactive retouching.
The pattern most studios converge on: ImageMagick for mechanical conversions, UXP/BatchPlay for anything that needs Photoshop's logic, droplets for retoucher self-service, and IP/IPP for last-mile finishing on the desk.
Output presets the studio actually needs
Whatever tool runs the batch, the rendition list is the same shortlist for a packshot studio:
- sRGB JPG, 2000 px long edge, quality 85, embedded ICC, metadata stripped - the PDP master for the e-commerce CMS. Most platforms re-encode anyway, but you want the source clean.
- sRGB JPG, square crop, 1200 px, white background - the marketplace rendition (Amazon, Zalando, Shopify channel apps). Square aspect is non-negotiable on most marketplaces.
- AdobeRGB TIFF, full resolution, 16-bit, layers flattened, embedded profile - the archive master. Use this for reprints and re-licensing; never deliver it to a web channel.
- PSD, layered, full resolution - the editorial source. Lives in the DAM, not in the delivery folder.
The mistake worth avoiding is setting up "one big render" that produces all four from one IPP run. Different channels have different naming, different metadata rules, and different review steps. Run them as separate presets so you can ship the PDP rendition while archive TIFFs are still encoding. The color-managed retouching pipeline article covers profile handling per rendition in detail.
File-naming tokens inside the IP/IPP UI
Plain Image Processor's naming is rigid: <original-name> plus a per-format suffix and a per-size suffix the script appends itself. There is no token UI. If naming matters - and at studio scale it always does - IPP is the minimum.
IPP exposes four tokens in its naming field: Document Name (the source filename minus extension), Prefix (a string you set per preset), Suffix (likewise), and Sequence Number (with a configurable starting value and digit count). You build a name like {prefix}_{docname}_{suffix}_{seq} and IPP fills it for each output. This is enough for most channel-naming schemes - pdp_SKU12345_2000_001.jpg is one preset away.
What IPP cannot do: pull tokens from XMP metadata, from a CSV sidecar, or from a job ticket. If your filename needs the SKU from a PIM and the season code from a job brief, that mapping has to happen before the file reaches IPP, or after. In a managed pipeline, the file arrives with the SKU and season already in its name and metadata; IPP just renders.
Where IP/IPP fits - and where a managed pipeline takes over
Image Processor Pro is a finishing tool. It belongs on the retoucher's desk, for late-stage adjustments, one-off client requests, and recovery jobs. Trying to run a studio's entire export through it is the same pattern as running production through a spreadsheet: it works at small volume and quietly costs you a person at large volume.
A managed pipeline takes the parts that are not creative - file naming, rendition matrix, channel-specific exports, delivery, audit log - and runs them downstream of Photoshop. The retoucher commits a layered PSD into the DAM, and the pipeline produces the PDP JPG, the marketplace square crop, and the archive TIFF, names them against the SKU, and pushes to the distribution module. The retoucher never opens IPP for the bulk run; they open it when something specific needs hand-finishing.
This is the split editors and retouchers tend to land on once the volume is real: scripts and ImageMagick for mechanical work, UXP for studio-internal automations, IPP for the desk, and a managed platform for everything between the retouching app and the channel. The QA process lives on top of that platform, not inside the export script.
A short checklist before the next batch run
- Can you name, in writing, which renditions go to which channel and in which color space?
- If the IPP run crashes at file 1,400 of 2,000, do you know how to resume without re-rendering the first 1,400?
- Does the retoucher's workstation get blocked during exports, or do batches run somewhere else?
- Does every exported file land in the DAM with its SKU, season, and job ID already on it?
- If a buyer asks "which JPG was delivered to Zalando on 14 March?", can you answer in under a minute?
If three or more answers are uncomfortable, the problem is not the script. It is that batch export is still the retoucher's job, and at studio scale it should not be.