How The DAM Pairs RAW Files With Their Edits

Photography

A photograph is not always one file.

It may begin as a camera RAW file, acquire an XMP sidecar, become a full-resolution TIFF or JPEG, and produce separate Web, social, press, and print exports. A normal folder makes those relationships understandable to a person. A DAM needs to preserve them without confusing a derivative for a new creative work.

I needed the system to distinguish the photograph from the files made from it.

Identity Comes Before Organization

The ingest pipeline starts with a read-only inventory. It records paths, sizes, extensions, and timestamps without moving or renaming anything.

It then calculates a SHA-256 hash for exact identity. The hash answers a narrow but important question: have these exact bytes already been seen?

A UUID provides the asset’s durable internal identity. The original camera filename remains intact, especially for RAW files, because renaming can break sidecar and editing-tool relationships.

Folders remain useful for humans, but neither a folder nor DSC_1234 is globally unique.

Grouping Uses Several Clues

The next phase extracts EXIF, IPTC, and XMP metadata. Grouping can then compare:

  • Filename stems and known export suffixes.
  • Capture timestamps.
  • Camera metadata.
  • Dimensions and file formats.
  • Existing sidecar relationships.

A RAW file and a JPEG with a matching stem and capture time are strong candidates for the same asset family. A social export with a known suffix can be attached as a rendition rather than cataloged as an unrelated photograph.

I would rather leave a questionable pair for review than manufacture a clean-looking family tree. Automation should reduce sorting work, not quietly create false lineage.

One Creative Work, Several Representations

The resulting model looks less like a flat media library and more like a family tree:

asset
  master: camera RAW
  sidecar: XMP
  edit: full-resolution TIFF or JPEG
  rendition: web
  rendition: social
  rendition: print

Originals are committed as read-only. Library views use links rather than duplicate copies, allowing one asset to appear under year, event, artist, or platform without multiplying storage.

Why This Matters

The difficult part of a photo archive is not storing bytes. It is retaining enough context to know which bytes are authoritative, which are edits, and which can be regenerated.

Hashing solves exact duplication. Metadata and naming conventions suggest relationships. Human review handles ambiguity. Immutability protects the result.

Together, those choices let the archive evolve without requiring camera filenames to carry the weight of an entire asset-management system.