A batch workflow for photographers: masters, proofs and deliverables

The difference between a photographer who spends an hour on delivery and one who spends a day is rarely editing speed. It is whether the post-editing steps — sizing, naming, watermarking, packaging — are a defined pass or an improvised one.

Three tiers, defined once

Almost every shoot produces the same three categories of file, and confusing them is where time disappears.

Masters. Full resolution, minimally compressed, in your working colour space, with capture metadata intact. These are archived and never edited in place. Every other file is derived from them.

Proofs. Small, watermarked, for client selection. Their job is to be viewable and unusable as finals. 1200 pixels on the long edge is plenty; a visible watermark is the point rather than a compromise.

Deliverables. What the client actually receives, sized for what they will do with it. Usually two sets: full-resolution files for print and web-sized files for their site and social.

Defining these three once, with fixed settings, means each shoot is the same three passes rather than a series of judgement calls.

Long edge, not width

For mixed portrait and landscape work — which is every shoot involving people — sizing by width is the wrong instrument. Set 1200 pixels wide and your landscapes are 1200 across while your portraits are 1200 across and 1800 tall, so they dominate the gallery.

Sizing by longest edge fixes this. Every image, regardless of orientation, ends up the same maximum dimension, and they sit together at consistent visual weight. This is what galleries and portfolio platforms want, and it is why the option exists separately from width and height.

Naming that survives the client

Camera filenames collide. Two bodies both produce DSC_0001, and a second card produces the same names again after 9999 frames. Handing a client a folder of IMG_4021.jpg guarantees that when they email you in eight months asking for "the one of the harbour", nobody can find it.

A pattern that works: client-shoot-YYYY-MM-DD-NNN. The client and shoot make it findable, the ISO date sorts correctly and disambiguates repeat bookings, the padded sequence keeps order.

Rename as part of the export pass, not by hand afterwards. Hand-renaming across two hundred files is where inconsistency enters.

Watermarking proofs, and only proofs

Proofs get an obtrusive mark because their purpose is selection, not use. Deliverables get either no mark or a discreet one, depending on your agreement.

Size the mark as a percentage of image width so a mixed batch stays consistent, and keep opacity in the 60–85% range so it reads without obliterating the image. Corner marks are trivially cropped; if the proof genuinely needs to be unusable, the mark has to sit somewhere that removing it damages the frame.

Colour, before export

Convert to sRGB for anything going on screen — proofs, web deliverables, social crops. Keep your wider working space for masters and for files going to a print lab, which will tell you what it wants.

This is worth doing before the batch pass rather than after, because tools that re-encode images generally do not carry colour profiles through.

The delivery pass, concretely

For a typical shoot of 300 selected frames:

1. Archive masters. Full resolution, untouched, backed up in two places before anything else happens.
2. Proofs. Long edge 1200, quality 80, watermark at 6% of width, renamed with the shoot pattern. Deliver as a ZIP or a gallery link.
3. Web deliverables. Long edge 2048, quality 85, sRGB, no watermark or a discreet one, same naming.
4. Print deliverables. Full resolution, quality 95, in the lab's requested colour space, same naming so files correspond across sets.

Steps two through four are each one batch operation with saved settings. The whole delivery is minutes of processing rather than an afternoon of exports.

Keep the masters out of the pipeline

The single most important rule: never run a batch over your masters in place. Every step here is destructive — resizing discards pixels, compression discards data, re-encoding discards metadata — and none of it is reversible.

Process from masters, write to a separate output folder, and treat the masters as read-only. If a client comes back in a year wanting a different size, you want to be re-deriving from originals, not upscaling a proof.

On uploading client work

Worth a moment's thought: many convenient batch tools work by sending files to a server. For a wedding, a corporate shoot under NDA, or anything involving children, that is a third party receiving images your client did not agree to share.

Processing locally removes the question entirely, and it is faster anyway once you account for upload time on a folder of 300 full-resolution frames.

Storage, and what to actually keep

The instinct to keep everything collides with the reality that a wedding produces 60 GB of raw files and a busy year produces several terabytes.

A workable policy: keep every selected master indefinitely, keep the raws for the selects, and delete the rejects once the client has signed off. Derived files — proofs, web sizes, social crops — are regenerable from masters and do not need archiving at all. Deleting them is free, because reproducing them is one batch pass.

Two copies in two places is the minimum that counts as a backup, and one of them should not be in the same building. A cloud sync of a working folder is not a backup, because it faithfully replicates a deletion.

Handling the reshoot request

Clients come back. Eight months later they want the harbour shot for a billboard, or a square crop for a new profile, or the whole set at a size nobody discussed originally.

This is the moment that reveals whether your archive was organised. If the masters are in a dated, client-named folder with filenames that match what you delivered, the request is a five-minute batch pass. If the only surviving files are the web-sized deliverables, the honest answer is that you cannot do it — and upscaling a 2048-pixel proof to billboard size is not a substitute.

Filenames that persist across every tier are what make this work. When the client says "image 047", it should be findable in masters, proofs and deliverables alike.

Where the time actually goes

Photographers usually assume delivery is slow because exporting is slow. Measured honestly, the export is minutes and the decision-making is hours: choosing a size for this client, deciding whether to watermark, working out a naming scheme on the spot, checking whether the colour looks right.

Fixing the settings once — as saved presets for proofs, web deliverables and print deliverables — removes the decisions rather than the processing. That is where the hour-versus-day difference comes from.