The Hidden Work of Managing Multiple Versions of the Same Photograph

Why Photographers Love Their Tools · An editorial collection from Zippi Technologies. We develop Lightbox Pro; these are educational explanations, not independent product rankings or measured competitor tests.

A version is a relationship, not just a suffix

A photographer finds an original RAW, a camera JPEG, an edited TIFF, a retouched PSD and several delivery files. Their thumbnails resemble one another. That resemblance does not tell the photographer which files can be recreated, which contain unique work or which record a client’s approval.

Version management is the work of preserving those relationships. A useful record says where a file came from, what it is for, which decisions it contains and what later work relies on it. A filename can help communicate that record, but cannot reliably carry every part of it.

This guide follows a fictional photograph identified as Vale-B0147. The source produces a working interpretation, a retouched master and several outputs. The example is a proposed studio method, not an implemented Lightbox Pro version-graph feature or an account of a real client job.

The duplicate and similar-photo guide answers a different question: how to investigate apparent redundancy. Here, the aim is to make a photograph’s legitimate versions understandable before anyone considers cleanup.

Give every representation an explicit role

The original RAW preserves the capture source. An initial JPEG may be a camera-produced preview or a proof made later; record which. An edited TIFF can be a handoff rendering, while a PSD can be an editable retouch master. The role is not determined by the extension alone.

Print, web, album and client-delivery versions can each have distinct crops, profiles, dimensions and approval conditions. A file used in two destinations may satisfy both, but that should be an explicit decision. Do not assume that all small JPEGs are expendable or that every large file contains unique work.

Scroll within the table to read all columns.

Some roles may share one file in a simple job. Others may require several revisions. The record should reflect the work actually performed rather than forcing every photograph through eight mandatory containers.

Draw the relationships before changing the naming scheme

A straight chronological list can imply that the newest file replaces everything before it. Photographic work often branches instead. The web output and print output may both descend from the same accepted master, while a later alternate crop creates another valid branch.

Use arrows to mean “derived from,” not merely “created later.” A file copied after the print output can still be a copy of an earlier master. Creation or modification time alone does not establish photographic ancestry.

When a derivative combines several sources, record all required ingredients. A composite cannot be explained completely by a single-parent filename. Keep the construction’s dependencies with the working project.

Use a stable source key and a separate revision

Give the exposure a stable job-specific key, such as Vale-B0147, and keep that key in the mapping for every representation. Use a separate revision for changes to an interpretation or master. This avoids conflating “another file format” with “another accepted photographic decision.”

A practical output name might include the source key, role and revision: Vale-B0147-web-r02.jpg. That is a proposed naming convention, not a standard every program understands. Keep the relationship ledger as well, because clients may rename files or a destination may impose its own naming rules.

Adobe’s XMP media-management namespace defines properties for identity, derivation and versions. Their existence does not guarantee that every tool populates, preserves or interprets them consistently. Inspect the actual files and supported workflow before relying on embedded identifiers as your only version record.

Keep human-readable labels concise. An extremely long filename encoding every edit can become less useful than a short stable key plus a clear ledger. The goal is that another person can identify the intended source and revision without interpreting an elaborate private code.

Separate a saved interpretation from a new pixel file

Lightroom Classic virtual copies store alternative adjustment records in the catalog rather than creating independent photograph files immediately. Exporting or external editing can create physical derivatives. This distinction matters when estimating storage and deciding what must be preserved.

In the Vale example, a warmer interpretation and a monochrome interpretation can share the same source. They are different photographic choices even before either becomes a delivery file. Their reproducibility depends on retaining the relevant catalog or processing record and a compatible way to interpret it.

A rendered master can preserve an accepted appearance while offering different editability from the original processing record. Neither representation automatically makes the other redundant. Decide which future revisions the job needs to support before removing one.

Do not assume that an XMP sidecar carries every organizational or creative state from every catalog. Verify the relevant properties and supported transfer route. A copied sidecar is a file, not a universal promise of complete application-state portability.

Decide what causes a new revision

Write a small policy for the studio. A change to visible retouching or the accepted interpretation should normally produce an identifiable new working revision. A byte-for-byte copy to a recovery drive is another location of the same file state, not a new creative revision.

Destination changes can be tracked separately. A new web size from master r02 might be another rendition of r02. A new master r03 that changes the repair requires reviewing the outputs that depend on that repair. Naming the relationship makes that review scope visible.

A metadata correction may also matter even when pixels do not change. Correcting a caption or rights field can require a new delivery record. The public-facing image may look identical, yet the file is a different release artifact with a meaningful difference.

Keep accepted revisions immutable in the release record. You can continue working, but the record of what was approved or delivered should retain its identity. Reusing “final.jpg” for each new state can erase that evidence while giving every version the same reassuring name.

Late changes should travel only to the affected branches

The client requests a tighter web crop while the print and album versions remain accepted. Return to the appropriate master and make a new web rendition. There is no reason to rebuild unrelated branches unless the change exposes a common problem.

Now suppose the client asks for a visible retouch correction in the master. Identify which outputs descend from that master state and review whether each needs replacement. A ledger makes this a bounded dependency question rather than a search for every file with a similar thumbnail.

For album work, distinguish updating the input rendition from approving the resulting placement. The same master revision can be used differently across spreads, and a new crop can alter the layout even when the underlying exposure remains the same.

The gallery-to-album reconciliation procedure handles that boundary. The general version lesson is that a change’s effect should follow its dependencies, not simply every file produced on a later date.

Use file hashes for identity of bytes, not identity of meaning

NIST describes cryptographic hash functions and their intended collision-resistance properties. A properly computed full-file hash is useful evidence when comparing copies or detecting a changed file. It answers a byte-level question.

Two different exports of the same accepted photograph can have different hashes because metadata, compression or other packaging differs. They may still share a photographic role, but they are not identical files. Conversely, two identical files stored on one failing device do not provide independent recovery merely because their hashes match.

For Vale-B0147, record the hash of the exact released file when a precise delivery record is useful. Keep the photographic source/master mapping alongside it. A hash alone cannot tell a colleague whether a file was approved, what it depicts or which crop the client requested.

Do not replace the human-readable ledger with a wall of checksums. Use technical evidence to support a clear record. The person answering a client request needs both the intended photograph and confidence that the selected file is the recorded release.

Keep metadata roles consistent across versions

Descriptive, rights and administrative information serve different purposes, as IPTC explains. A version workflow should define which fields belong in the source record, working project and outgoing file. A private retouch instruction is not automatically appropriate public metadata.

When a caption changes, decide which future exports should inherit the correction and whether earlier deliveries need replacement. Preserve the historical record rather than silently rewriting what the original recipient received. A current correct caption and a past release record can coexist.

Check whether the export route includes, omits or transforms the required fields. A field visible in the catalog may not be embedded in the output. An embedded field may survive one application and be removed by another. Inspect the actual handoff when that field matters.

Keep source identity stable through those operations. A file can receive corrected metadata without becoming a different exposure, while its byte-level release identity changes. The distinction helps avoid both false duplicate alarms and inaccurate claims that nothing changed.

Preserve the master’s external dependencies

Linked Photoshop Smart Objects refer to external files. Similar dependency issues can occur with other project-based workflows. A saved document may look complete while still requiring material stored elsewhere.

For the example, keep a project manifest listing any linked background, required rendering reference and the exact master state used for outputs. Verify the package on a copied location. Do not assume a composite preview proves all editable components remain accessible.

If a dependency is intentionally flattened into a delivery, record that the delivery has different editability from the working master. Flattening can be appropriate for a destination while still being unsuitable as the only surviving production record.

The RAW-to-Photoshop procedure gives a concrete return and packaging check. Version management adds the broader question: which later branches would become difficult to revise if this dependency were lost?

A cleanup and recovery exercise

Before deleting temporary material, choose one released photograph and explain every retained representation. If a file’s role is unknown, investigate rather than labelling it redundant. Large size and an old modification date do not establish that it is expendable.

Classify a cleanup candidate as recreatable intermediate, unique editable work, release evidence or intentional recovery copy. A recreatable intermediate can be considered separately only after the source, processing record and required software route are verified. Keep the cleanup decision in the job record when its consequences matter.

Then restore a copied Vale project into a separate location. Locate the source, open the master with dependencies, identify the accepted release and reproduce one destination output. Record anything that cannot be recovered or interpreted without the original workstation.

This exercise distinguishes tidy storage from durable work. A smaller folder is not automatically a better archive. A useful archive is one in which the photographer can explain what remains, retrieve the intended photograph and perform the revisions the job promised to support.

Read a revision ledger as a sequence of decisions

A compact Vale-B0147 ledger begins with capture source S01, development D01 and retouch master M01. The first web output W01 and print output P01 both descend from M01. These are teaching identifiers, not an external metadata standard or a naming syntax automatically recognized by applications.

The client then requests a local repair, producing M02. New outputs W02 and P02 descend from M02 and replace the earlier deliveries for their stated purposes. Retain W01 and P01 as historical release evidence if the job’s policy requires that record; they are not current simply because they still exist.

Later, an alternate monochrome treatment D02 is prepared from S01. It is a new interpretation branch, not a replacement for the color master by default. If it receives separate finishing, name that master and its outputs on the new branch. The shared capture identity helps retrieval while the branch identity preserves the creative distinction.

A request for an album crop can then refer specifically to M02 rather than to whichever JPEG the client happens to have renamed. Create the album-ready rendition and record its project use. If a layout later changes without changing the master, update the placement/project record rather than inventing another RAW source revision.

Walk backward from each current output. W02 leads to M02, then the accepted development and source. The monochrome output leads to its own branch. Any file that cannot be traced deserves review, even if its name contains the correct exposure key.

Walk forward from a proposed master change as well. Which outputs and project placements would need inspection? This direction is useful when a subtle repair must be propagated. It prevents the newest file from being treated as a universal replacement for every earlier creative branch.

Keep the ledger understandable to someone who did not perform the edits. Explain what each identifier means and which state is current for each destination. A technically complete graph that only its author can interpret is a weak professional handoff.

Finally, preserve the ledger with the project’s recovery material. If the relationships exist only in a temporary note on the editing workstation, the files can survive while their meaning is lost. Version management succeeds when both the photographic work and the explanation of its branches remain available.

What integration can and cannot promise

Lightbox Pro’s reviewed build 0.1.2 (71) implements catalog identities, saved versioned adjustment recipes and developing native corrected exports. That engineering is useful, but it does not establish the automatic cross-application version graph illustrated in this guide. General proprietary-recipe translation and complete hosted production services are not implemented.

Build 71 adds source-pixel Edit zoom and panning, plus asynchronous source-detail inspection that follows unapplied edits. Completed detail is reused during movement, but initial loading can still take time. RAW photographic-quality acceptance remains open. Native export includes flattened PSD rather than a layered retouch master. Those boundaries must stay clear when discussing a future workspace that connects sources, edits and deliveries.

The practical goal is a photograph whose relationships remain understandable as the work branches. Whether that is maintained in one application or several, it should be possible to answer: which source, which accepted master, which destination and which exact release?

Official references

1. Adobe XMP: media-management relationships
2. Adobe: virtual copies and physical derivatives
3. Adobe: Photoshop linked-object dependencies
4. NIST: cryptographic hash function
5. IPTC: descriptive, rights and administrative metadata

Product documentation checked 22 October 2026. Examples and worksheets are original teaching scenarios. Confirm the current version, camera support and terms before adopting a workflow.