I’ve edited photos for years, across four different tools — RawTherapee, Lightroom, Luminar, Darktable. All of them do “non-destructive” editing, which is a genuinely good idea: you never touch the original file. You record your edits separately, as a set of instructions, and the software replays them on top of the untouched original every time you open it.

It is the same idea I trust in data systems: keep the source immutable, log the transformations, and rebuild the result on demand. In practice, I had treated photo editors as event-sourced systems without asking whether their logs were portable.

Four tools left four incompatible histories

I have the same photos edited four different ways, in four incompatible formats, and most of that history I can no longer replay outside the exact tool that created it.

The originals are fine — that’s the part non-destructive editing actually promises, and it delivered. But my edits — a decade of actual decisions about these images — are scattered across four tools and a pile of catalog migrations, and only some of them are still legible to me. “Non-destructive” turned out to be a promise about the original file and nothing else.

RawTherapee stores a readable sidecar

RawTherapee writes its edits to a little sidecar file that sits right next to the photo. It’s plain text. You open it in any text editor and you can read every decision — the white balance temperature, the tone curve, the highlight-recovery method, the sharpening, the working color profile. Every knob, recorded in the open.

The sidecar is human-readable. I can diff two versions, see what changed, and replay it in a batch from the command line without opening the GUI. The original stays untouched, while the transformation history remains separate and inspectable.

Lightroom keeps the history in its catalog

Lightroom is also non-destructive. The edits are just as real, and the original is just as untouched. But the edits live inside a proprietary database, not next to the file — and you can only replay them inside Adobe’s software.

The log exists. You simply can’t read it, or move it, or replay it anywhere else. And it gets worse over time: my catalogs are organized by year, and every one carries migration suffixes — v10, v11, v12 — because each upgrade migrates the database schema. My edit history is a database that’s been migrated a dozen times and is legible to exactly one vendor’s app. The day I can’t run that app is the day that history is gone, originals notwithstanding.

Non-destructive does not mean portable

Here’s the distinction I’d missed. “Non-destructive” is a promise about the original: we won’t alter your file. That’s valuable and both tools kept it. But it says nothing about a completely separate property — whether you can still read and replay the log in ten years, move it to another tool, or understand it without the software that wrote it.

Portability of the log is its own thing, and it’s the one that quietly decides whether your history survives. A rich edit history trapped in a black-box database is worth less than a plain one you can read with a text editor, because the plain one will outlive the tool.

The same distinction applies to data systems. An event log or audit trail remains useful only while it can be interpreted and replayed. If the writing system is also the only reader, the history is tied to that product regardless of how carefully the original records were preserved.

What I preserve now

I now treat the original and its edit history as separate preservation problems. The source remains immutable; the log should also be readable, diffable, replayable, and movable without depending on one application.

All four tools preserved my photos. Only the plain-text history preserved the edits in a form I can still inspect without reopening the application that created them.

More on Local First The Data Was Already in the Browser →