Stop Retouching Notes From Landing on the Wrong Photo

Why filename matching sends notes to the wrong photo

A filename is a label, not an identity. Photoshop's own "Save As" habit appends a suffix by default. A retoucher working from a duplicate to protect the original renames the copy. A client who downloads originals to reference later renames them into their own folder scheme entirely. None of that changes which photo it is — but a system that keys off the filename string has no way to know that.

The failure is quiet. Nothing errors. A note written against frame IMG_4021.jpg simply doesn't show up when the open document is IMG_4021_edit.tif, and the retoucher has to go find it by hand — scrolling a gallery, comparing thumbnails, guessing from context which client note actually belongs to the file on screen.

The worse version of the failure isn't the lookup, it's a false positive: two frames that happen to share a filename, and a system confident enough to match them without asking. That doesn't cost a few minutes of searching. It puts a client's note on the wrong photo entirely, and nobody finds out until the round comes back and the note is still open — or, worse, closed against the wrong file.

What a mismatch costs, in minutes

Take a 30-image round where 8 files get renamed somewhere in editing — a mix of flattened exports and "just in case" duplicates, which is a normal rate for anyone who works non-destructively rather than editing the original in place. If each mismatch costs about 2 minutes of manual cross-referencing to find the right note, that's 8 × 2 = 16 minutes lost on that round alone.

Run that same round four times a week — a realistic pace for a solo retoucher juggling a handful of active clients — and it's 16 × 4 = 64 minutes a week. Over a month: 64 × 52 weeks ÷ 12 ≈ 4.6 hours spent re-identifying files that never stopped being the right photo, just stopped looking like it on disk.

None of that time shows up on an invoice, which is exactly why it's easy to undercount. It isn't billed as "file matching" — it gets absorbed into the round and shows up as a retouching pass that took longer than the last one for no reason anyone can point to. The arithmetic above uses round numbers on purpose: swap in your own rename rate and round frequency, and the shape of the cost holds even if the total doesn't match exactly. A studio running two retouchers through the same habits roughly doubles it, since the search time scales with people, not with any one person's workload.

Three ways to identify a file, in order

The panel tries three things, in a fixed order, before it ever shows a note against the wrong image:

The stamp is checked first because it's the only one of the three that isn't a guess dressed up as certainty. It's written into the file itself, so a rename, a Save As, or a move to a different folder doesn't touch it. Filename matching comes second, not first, precisely because a string comparison can look confident and still be wrong — it's a useful fallback, not a source of truth.

The order matters as much as the methods themselves. A system that checked the filename first and only fell back to metadata on a miss would still be vulnerable to the false-positive case: a filename match that happens to be correct-looking but isn't. Checking the stamp first means the fallback only ever runs when there's genuinely nothing more reliable to go on.

Why folder-aware matters, and why it still isn't the first check

That's still a second-best check. A folder can be renamed by whoever's syncing it; a file can be moved into a different one by whoever's tidying up. None of that is unusual, and none of it should be able to move a client's note onto a different photo. That's the case the ask step exists for: when the stamp is missing and the filename match isn't confident, the panel surfaces the choice instead of silently picking one.

A wrong guess and a slow confirmation are not the same class of problem, even though both cost time. A slow confirmation costs a few seconds and is over. A wrong guess costs whatever gets built on top of it — markup drawn on the wrong document, a note ticked closed against a photo the client never actually saw fixed — and it doesn't surface until someone notices the round doesn't match the notes, which can be days later. Asking once, up front, is strictly cheaper than that over the life of a round.

The same problem, worse, across a team

One retoucher renaming their own files is a manageable mess. Hand the same round to a freelancer working from their own folder structure, or split a shoot across two people, and filename collisions stop being an edge case — different people name working files differently as a matter of habit, and a system keyed on those names inherits every one of those habits as a potential mismatch.

Naming conventions rarely get agreed on in advance for a single round with a freelancer. One person's "_final" is another's "_v3", and a shoot handed off mid-project can arrive with a folder structure that has nothing to do with how the studio organizes its own files. A stamp that travels with the pixels sidesteps that negotiation entirely — it doesn't care what convention the folder above it is using.

A freelancer doesn't need an account to work this way, either — access to a round is a share link scoped to Retoucher permissions, revoked whenever the studio is done with them, and the file identity travels through the stamp regardless of whose folder it's sitting in.

Where a correctly stamped file starts

Most of this never comes up for files opened from the panel's own needs-work queue: clicking a frame there downloads the master, opens it, stamps it, and places the notes in one action, so the identity is already settled before editing starts. The mismatch problem shows up for the files that skip that step — one already open from a previous session, or handed over by someone editing outside the panel entirely — which is exactly why the fallback chain exists instead of assuming the queue is the only way a file gets opened.

It's worth treating the queue as the default path rather than an optional shortcut, for exactly this reason. A file opened any other way is starting from behind — relying on the filename fallback or the ask step from the first click, instead of arriving already stamped. Neither fallback is unreliable on its own, but a workflow that reaches for the queue first is a workflow that needs the fallback chain less often, not one that's protected against ever needing it.

Read more on what markup that lands directly on the file depends on getting this step right, and how that connects to tracking which notes are actually closed once the round comes back.