Version Stack vs Folder Names: Tracking Retouched Photos
Two ways to answer 'which file is current' — and what each one can't tell you when a client asks about round two.
A retouched photo goes through three, four, sometimes six rounds before a client signs off, and most studios track that history the same way: a folder, a filename, and a convention somebody wrote down once. IMG_0413_v2.jpg, then IMG_0413_v2_FINAL.jpg, then the one that actually shipped. It works until someone asks a question the filename was never built to answer — which round did the client approve, and what changed between round two and round three. A version stack is the alternative: instead of a naming convention, a database row per round, with the newest one current everywhere and every note stamped to the round it was written about.
This isn't an argument that folders are wrong. A single photographer editing alone never runs into the two questions above, because there's no second person who needs the answer. The moment a job crosses a boundary — client to studio, studio to a freelance retoucher, round two handed to someone who wasn't on round one — the filename stops being enough, and that's exactly the point where the two schemes below start producing different outcomes.
What folder names can't answer
A folder-and-filename scheme is doing real work — it answers "is this the latest file" well enough, most of the time, for one person working alone. It breaks on two questions that come up constantly the moment a second person (a client, an art director, a second retoucher) needs the answer too:
- Which round did the client actually approve? The filename says
_v2, but approval lived in an email or a Slack thread that has since scrolled away. Nothing on disk ties the file to the sign-off. - What changed between round two and round three? Unless someone kept both files and opened them side by side in a layer comparison, the honest answer is "open both and look," which is exactly the manual work a version system exists to remove.
Neither failure is a discipline problem. It's a structural one: a filename is a label, not a record. It can't carry a timestamp of approval, a link back to the notes that were open on it, or a diff against the round before it — because a string has nowhere to put that information.
The naming convention itself tends to drift for the same reason. _v2 is unambiguous until someone exports a proof at the same stage and calls it _v2_proof, or a second retoucher picks up the file and, not knowing the studio's exact suffix order, appends their own. None of that is carelessness — it's what happens when the only record of a round's identity is a string a person has to type correctly, every time, forever.
The cost of hunting for the right file
Put a number on it with the arithmetic in view, not asserted. Say a retoucher or coordinator spends 90 seconds confirming which file in a folder is the one the client approved — checking a filename against an email thread, or asking the photographer to confirm. That happens roughly twice per delivered round: once before starting the retouch, once before sending it out.
None of that is a measured average — it's one plausible set of inputs, shown so you can substitute your own studio's numbers. Swap in your own round count and shoot volume and the total moves, but the shape of the cost doesn't: it's a small, repeated tax that never shows up on an invoice because no client would pay for "time spent confirming the file was the right file."
The other cost is harder to put a clean number on but is usually the more expensive one: the round where the check doesn't happen. A retoucher works from what looks like the current file, delivers it, and it turns out to be one round behind — the client's newest notes were never addressed because nobody was looking at the version those notes belonged to. That's not 90 seconds of lost time; it's a full extra round, with the studio absorbing either the redo or the client's patience.
What a version stack actually tracks
A version stack replaces the naming convention with a row per round. Appruva's model is project → folder → image → image version: each image version is one review round, the newest is current everywhere in the app, and every note and every piece of markup is stamped with the version it was written about — so a delivered round shows what's outstanding on that round, not a mix of old and new comments. For a deeper look at how that current-version mirroring works across the gallery, see how Appruva tracks which edit is current.
The stamping matters more than it sounds like it should. A note written against round two ("lighten the shadow under the left eye") stays attached to round two even after round three ships. If the shadow was fixed in round three, that note shows as resolved on the round it was raised against; if it wasn't, it's still visibly open, rather than getting lost in a merged "all notes ever" list that can't distinguish an old complaint from a current one. That's the same structural gap a filename has — a string can't carry a status, but a stamped record can.
| Question | Folder names | Version stack |
|---|---|---|
| Which round did the client approve? | Only if someone wrote it down elsewhere | The approval is attached to the version record |
| What changed between R2 and R3? | Open both files and compare by eye | Rounds are placed underneath each other in Difference |
| What notes are still open on this round? | Not tracked by the filename at all | Notes are stamped to the version they were made on |
| What happens if two people work from different rounds? | Whoever has the older file overwrites the newer one | The newer version stays current; the older one is still there, just not on top |
Closing the loop from inside Photoshop
The place a version stack earns its keep is the handoff between the browser and the retoucher's desktop, and that's where Appruva's Photoshop panel does its work. The panel identifies which frame an open document is — an XMP stamp first, then a folder-aware filename match, then it asks — and shows the notes for it as badges, numbered to match what the client sees. Markup goes onto the file as its own layer, named for the round it belongs to (Appruva notes R2), so it's never confused with the retoucher's own layers, and it can be turned off entirely in favor of a small reference view of the frame with badges over it if the retoucher would rather not touch the layer stack at all.
Rounds themselves show up as chips in the panel — one per round that carries markup, newest first — and switching between them re-filters the notes already on hand rather than re-fetching anything: the layer rebuilds for that round, and Compare R−1 lays the previous round underneath in Difference, black wherever the two agree. That's the direct answer to "what changed between R2 and R3": not a description, a pixel comparison. Where a frame was recropped between rounds, the panel says the shapes won't line up rather than drawing badges that miss the target.
Delivery is where the version stack gets written. Deliver this image exports by the studio's recipe, uploads, stacks a new version, closes the notes that were ticked, and posts a delivery note saying what was addressed and what wasn't. A conflict guard checks first — if the frame moved to a newer round while the document was open, the panel says so instead of silently overwriting it, which is the exact failure mode a folder-and-filename scheme has no defense against. Deliver every open document does the same thing as a batch: exports run one at a time since Photoshop's own document operations are single-threaded, uploads overlap three-wide, one failure never stops the rest of the queue, and Retry re-runs only what failed. For the markup side of the same loop, see how client markup gets onto the file without a screenshot layer.
The panel's "export to this machine" option deliberately skips all of this — no upload, no version stack, no note closed. It exists for proofs and local checks, not delivery, precisely so it can't be mistaken for the real handoff.
When folder names are still fine
A version stack is solving a coordination problem, and coordination problems only exist when there's more than one person to coordinate with. A photographer editing their own personal work, with no client rounds and no second retoucher, loses nothing by sticking with folders — there's no approval to lose track of and no second person's older file to accidentally overwrite. The trade-off shows up specifically when a job crosses a boundary: client to studio, studio to freelance retoucher, round two to round three. That's also exactly where a filename convention was never designed to hold up, since it was built for one person's desktop, not a handoff.
The practical test is simple: count how many people, other than you, need to know which file is current on a given job. Zero people means a folder is fine, and adding a version-tracking layer on top of it is overhead with nothing to buy. One or more means every file that changes hands is a chance for the wrong round to travel — and that's the exact case a version stack was built to close.
Frequently asked questions
What's the difference between a version and a round in photo review?
They're usually the same thing described from two angles. A "round" is the review cycle — the client looks, leaves notes, the retoucher responds. A "version" is the file that round produced. In a version-stack model, each round has exactly one current version, and the version record is what carries the round's notes and approval status.
How do I know which version of a photo a client approved?
In a folder-name scheme, you generally don't unless someone documented it separately — the filename itself doesn't carry an approval state. In a version-stack model, approval is attached to the specific version record, so it travels with the file's history instead of living in a separate email or spreadsheet.
Does switching to a version-stack tool mean I lose my old files?
No — a version stack is additive. Earlier rounds stay in the system; they're just not the one marked current. The difference from a folder is that the system knows which one is current and which ones are history, rather than that being implied by a filename you have to remember the convention for.
Can I compare two rounds of a retouched photo side by side?
That depends on the tool. A folder-name scheme requires opening both files manually and comparing by eye. A version stack that's aware of rounds can place one directly underneath another in a difference blend, so only the pixels that actually changed are visible — which is a faster and more reliable check than a manual side-by-side.