Batch-Prepare Reference Images Without Overwriting the Originals
Batch-Prepare Reference Images Without Overwriting the Originals
A batch is one decision applied many times. That is the speed of it, and that is the hazard. Choose your settings while looking at the most convenient photograph in the folder, and you have made a folder-wide decision on the evidence of one file.
So start at the other end. Before you open any batch tool, write down what the destination actually needs. A treatment has a page size, an export scale, a largest image placement, and an app that will open the files. Those four facts decide the working copy. Everything after that is execution.
Specify what must survive the conversion
Write the requirement in four lines, because four is roughly the number of things that go wrong: maximum dimensions, accepted formats, color handling, naming.
Take the ceiling seriously and derive it. If the layout page is 2,000 px wide, the largest image in it occupies about 1,200 px across, and the deck exports at 2×, then the biggest working copy you need is 2,400 px on the long edge. That is a number with a reason behind it, and reasons survive contact with a client asking why the folder is bigger than expected. "That's the preset" does not.
Two distinctions matter more than any single value.
Fit within a bound, don't force a fixed size. A 3,000 × 4,500 portrait and a 5,400 × 3,600 landscape both fit inside a 2,400 px long edge, and they come out as 1,600 × 2,400 and 2,400 × 1,600. They stay the shape they are. If a route offers you exact output dimensions instead, that is a crop or a stretch wearing a resize's clothes, and it will quietly remove the composition you chose the reference for.
A maximum is a ceiling, not a target. A 900 px graphic does not need to become 2,400 px. Upscaling invents interpolated pixels and produces a larger file that is no more informative than the original. The ceiling tells you where to stop, not where to aim.
Now look at what the folder actually contains. Here is a constructed folder for a treatment — a paper example, not a run that was performed for this article:
refs_treatment_04/
A_wide_kitchen.jpg 5400 x 3600 sRGB
B_portrait_hand.jpg 3000 x 4500 sRGB
C_mark.png 900 x 900 transparent
D_cereal_scan.tif 4800 x 3200 untagged
E_fabric_p3.jpg 4000 x 2667 Display P3
Five files, and the three the uniform rule does not suit fail in three different ways. The wide photograph and the portrait are unremarkable — those are the two your preset was designed for. The transparent mark cannot survive a format that has no alpha channel. The scan is carrying fine lettering that may not survive a halving of its pixel count. The fabric swatch was selected because of a saturated color, which is the first thing a narrower profile conversion gives up.
Before any of that, preserve the sources. Copy nothing, move nothing, and record each file's catalog identity — its source, its authorization, its role in the treatment — while you can still see the original folder intact. A derivative that cannot be traced back is a loose end, and the trace is cheapest to establish now.
Trial the shared settings on the awkward inputs
Photoshop's Image Processor is the named route here. Adobe's documentation for it — the page revision supplied here is dated February 23, 2026, checked on September 18, 2026 — describes a batch that can output JPEG, PSD and TIFF, resize by proportional fit, set profile options, and apply the first image's settings to the rest of the files. That page also describes source selection, an explicit destination, and the file output options. The URL is https://helpx.adobe.com/photoshop/desktop/automate-tasks/process-a-batch-of-files/convert-files-with-the-image-processor.html
Two limits belong right next to those sentences. The documentation describes controls; it does not settle how this route handles a transparent input, and the listed output formats do not establish a general transparent-image export path. Nor is it a substitute for running your own files through it. Documentation tells you what a control claims to do. A trial on your own awkward inputs tells you what your folder does.
The first-image trap, before you turn it on. "Apply first-image settings to other files" is a convenience that converts one file's needs into the folder's rules. If the first image is A, then every choice you made while looking at A — format, ceiling, profile — becomes the default for four images nobody examined. That is not neutral; it is a decision wearing a default's clothing. On a heterogeneous folder, treat the shared settings as a short list you can write down and defend, one line at a time, rather than as an inheritance.
Build the trial from the awkward cases, not the easy one. Run three files first: one photograph as a control, plus the transparent graphic and the fine-lettering scan. The photograph is there so you can tell whether the shared settings are behaving at all. The other two are there to fail.
Work the constructed example through on paper. Shared settings: output JPEG, fit within 2,400 px, convert to sRGB.
- A and B come out as expected, 2,400 × 1,600 and 1,600 × 2,400. The shared rule was written for images like these.
- C, the transparent mark, is the one the batch had almost nothing to do. At 900 px it already sits under the ceiling. The only thing the shared rule changes is the format — and JPEG carries no alpha channel, so the cut-out arrives flattened onto a solid rectangle. Placed on the layout's dark panel, that rectangle is visible as a box. The failure was caused by the format rule alone, which is why it would never have shown up in a test of the size rule.
- D, the scan, is halved from 4,800 px to 2,400 px and compressed at whatever quality setting keeps the folder small. In the deck's type-detail panel, where that lettering is shown larger than the base placement, the counters of small serif characters begin closing up.
- E, the fabric, is converted from Display P3 into sRGB. The very saturated orange that made this swatch worth referencing maps toward something duller. The file is not broken. It is less true, in exactly the dimension you selected it for.
No conversion was executed to produce those outcomes. They follow from format rules and arithmetic: JPEG has no alpha channel, a 2,400 px ceiling halves a 4,800 px scan, and an sRGB conversion maps colors that fall outside sRGB. Those are properties of formats and numbers, not of one dialog.
The paper walkthrough ends in a split. A and B stay on the shared rule. C, D and E leave it, for three different reasons — format, pixel count, profile — and none of them is a mistake. The exception list is the deliverable as much as the images are.
Run the batch, then reconcile files rather than count blindly
Run the batch to a destination outside the source tree. This is the cheapest protection you will ever buy, and it is also the place overwrites happen: process a folder of JPEGs to JPEGs, with a naming scheme that reuses the original stem, into the original folder, and you have replaced your sources with derivatives. Nothing will warn you. The originals are simply gone, and the derivative is now the only copy, which means it is now the original.
Keep a source-to-output list, not a tally. Here is what the constructed fixture should produce:
| Output | Source | Departs from the shared rule because |
|---|---|---|
working/A_wide_kitchen__w2400.jpg |
A | — |
working/B_portrait_hand__w2400.jpg |
B | — |
working/C_mark__cut.png |
C | format: alpha must survive; none of the named route's listed outputs carries it, so this one still needs a route of its own |
working/D_cereal_scan__w3200.jpg |
D | size: the detail panel needs the pixels |
working/E_fabric_p3__w2400_p3.tif |
E | profile: P3 retained for the color-managed layout |
working/E_fabric_p3__w2400_srgb.jpg |
E | profile: an sRGB copy for the sRGB-only review PDF |
Five sources, five derivatives produced and a sixth still waiting on a route that can carry alpha, with one source producing two of them. A count would tell you nothing here. Read as a number, 6 against 5 looks fine — but the same count would look fine if A had silently dropped out of the run and E had produced three derivatives instead of two. Only the list distinguishes a failed input from a renamed derivative from an intentionally separate exception. Failures in a batch are usually silent: a file the route could not read produces no output and no error you will notice, and the folder looks tidier for it.
Naming carries the trace. Reusing the source stem with a marker appended keeps every derivative answerable to its source, and it also surfaces collisions — two source folders each containing an IMG_0042.jpg will otherwise produce one derivative and a mystery.
Then resist the tidy-up. Do not delete originals, do not strip useful source metadata to make extensions look uniform, and do not flatten a transparent file just to get a consistent folder. Check the promise directly: after the run, the source folder's contents and modification dates should be unchanged. If they moved, you wrote into the source tree.
Finally, record the settings and the application edition that produced the set. Batch behavior changes between versions, and "which build made these" is the question you cannot answer from the images alone.
Inspect the references at their actual treatment use
A successful conversion is not evidence of usable output. Inspection is where you find out.
Compare representative originals and derivatives under the same viewing conditions — same display, same profile, same application, side by side. Opening a TIFF in one app and a JPEG in a browser tab compares two renderings, not two files.
Check four things on each representative pair:
Orientation. Photographs can carry an orientation flag, and routes differ in whether they honor it, ignore it, or bake it in. Look at the portrait photograph and confirm it arrived portrait.
Transparency, where it applies. Put the cut-out over the background it will actually sit on, not over a checkerboard. The checkerboard flatters a flattened file; the dark panel does not.
Fine detail, at the size it will be used. A scan inspected at 200% on a large monitor is a test of your monitor. Place the working copy at the size it occupies in the deck and look at it there.
Color. Check the saturated reference against the source under the same conditions, and expect a difference if you narrowed the profile. The question is whether the difference touches the feature you selected the image for.
Where a conversion has changed the feature that made the reference useful, you have two honest options: change the processing route, or keep a source-derived alternative for that use. For D, that means a larger ceiling. For E, it means retaining the P3 file as the color authority and labelling the sRGB copy as the one that carries a known shift. Both are decisions; neither is a defect.
Only then inspect a placed sample inside the treatment itself. Conversion can succeed completely and the exported treatment still be wrong — the image may be cropped by the frame, sunk under a translucent panel, or resampled again on export. The file being correct and the reference doing its job are two different claims.
What the folder should say when you're done
You should be able to account for every source and judge every derivative: this file went through the shared rule, this one left it for a reason, this one produced two versions because there are two destinations, and this one is sitting on the exception list until a route that can carry its transparency is established.
The mixed walkthrough, with three files out of five outside the shared rule, is not an embarrassment to hide before you show the folder. It is the explanation for why the folder is not uniform. Batching repeats decisions — the useful part is deciding which decisions deserve to repeat.
Frequently asked questions
How do I derive the maximum working size for batch-prepared reference images?
From the destination: layout page size, largest image placement, export scale and the app that opens the files. For example, a 2,000 px page with a 1,200 px image exported at 2x needs a 2,400 px long edge. Treat it as a ceiling, not a target; do not upscale a smaller image just to reach it.
Why can one shared batch setting fail a mixed folder?
A batch applies one decision many times. A transparent graphic needs alpha, a fine-lettering scan may need pixel count, and a Display P3 fabric swatch may need its profile. A JPEG rule can flatten the cut-out, a 2,400 px ceiling can halve the scan, and an sRGB conversion can dull the saturated color the swatch was chosen for. Those are different failures from one rule.
What is the risk of applying first-image settings to the rest of the files?
It converts one file's needs into the folder's rules. Every choice made while looking at the first image — format, ceiling, profile — becomes the default for images nobody examined. On a heterogeneous folder, treat shared settings as a short list you can write down and defend rather than an inheritance.
How do I avoid overwriting the originals?
Run the batch to a destination outside the source tree. Processing a folder of JPEGs to JPEGs, with a naming scheme that reuses the original stem, into the original folder can replace sources with derivatives without warning. After the run, the source folder's contents and modification dates should be unchanged.
What should I inspect after running a batch?
Compare representative originals and derivatives under the same display, profile and application, side by side. Check orientation, transparency over the actual background, fine detail at the size it will be used, and color. Then inspect a placed sample inside the treatment, because a conversion can succeed while the exported treatment still crops, covers or resamples the reference.