WINDER
All articles

How to Organize Film Scans So They Outlive Your Apps

Six rules for a scan library that still opens in twenty years: folders as albums, filenames that sort themselves, metadata beside the photograph, and a delete that isn't one.

By The Winder Team7 min read

How to Organize Film Scans So They Outlive Your Apps

A roll of film is an object. Its scans are not — they are a few hundred megabytes that will move between four computers, three phones and at least one service that shuts down. The question isn't where to put them this week. It is whether you will be able to open them in 2046.

The answer is boring and it works: keep the photographs as files, in folders, with their information written beside them. Six rules.

Why catalogs rot

Most photo software keeps your library in a database — a proprietary file that maps images to albums, keywords, ratings and edits. It is fast, it is searchable, and it is a single point of failure.

The failure modes are all mundane. The company folds. The subscription lapses and the catalog goes read-only. A migration to the new version half-succeeds. A sync conflict picks the wrong side. The database is fine but the app won't run on the current OS.

In none of those cases do you lose the JPEGs — you lose everything you said about the JPEGs. The dates, the places, the album that made them a trip. That is the part that took you years to build, and the part that lives nowhere else.

So: the photographs go in folders, and everything you know about them goes next to them, in a format a text editor can read.

Rule 1: the folder is the album

One folder per roll, named the way you would name it out loud.

Film/
  Rome, May '26/
  Kodak Gold, backyard/
  Roll 260806/

No app required to browse it, no import step, no "where did it go". Rename the folder in Finder and the album is renamed. Drag a photograph from one folder to another and it has moved. The file system is a perfectly good database that every operating system ships with and no company can discontinue.

A caution: folders are exclusive — a photograph is in exactly one. If you want overlapping groupings (Portraits, 2026, Shot on Gold), those need to be labels stored in the file's metadata rather than folders, because a photograph can wear many labels and live in one folder.

Rule 2: name files so they sort themselves

A filename is metadata that survives everything. Make it carry the two things you always want: when, and which frame.

WDR-260504-0001-A.jpg     ← 2026-05-04, frame 1, left half
WDR-260504-0001-B.jpg     ← the right half of the same scan
WDR-260504-0002-A.jpg

The rules that matter more than the exact scheme:

  • Date first, in yymmdd or yyyymmdd. It sorts chronologically in every file browser on earth, forever.
  • Zero-pad the counter, or 10 will sort before 2.
  • Keep the half-frame pair adjacent. If one scan became two photographs, the filenames should say which two — you will want to print them together.
  • Never rename a file to fix an error. Fix the metadata; the filename is an address, and addresses that change break links.

Rule 3: metadata belongs beside the photograph

Two places, and you want both:

EXIF, inside the JPEG. Camera, lens, date taken, GPS. Every viewer on every platform reads it, and it travels with the file when you send it to somebody. For film this has to be written after the fact — the camera didn't do it — which means whatever tool splits or imports your scans should also stamp them.

A sidecar, next to the JPEG. A small JSON or XMP file holding the things EXIF has no good field for: which albums the frame belongs to, whether it's a favourite, notes, the name of the place rather than its coordinates.

Rome, May '26/
  WDR-260504-0001-A.jpg
  WDR-260504-0001-A.json    ← date, place, albums, favourite, notes
  roll.json                 ← camera, lens, film stock, scanner, scan date

Sidecars sound fussy and are the opposite. They are plain text, human-readable and diff-able; they survive being copied to another drive; and if the app that wrote them disappears, you can still read every word with TextEdit. A database row cannot say that.

One more economy: put anything that is true of the whole roll — camera, lens, film stock, who scanned it — in one file at the roll level, not repeated in seventy-two sidecars. One body and one film shot the whole roll; say it once.

Rule 4: a delete should not be a delete

Nothing you have scanned should ever be one tap from gone. Deleting moves a file to a .trash/ folder inside the library, where it sits until you deliberately empty it.

This costs a few gigabytes and buys back the frame you deleted at midnight because it looked soft on a phone screen and turned out to be the best one on the roll.

Rule 5: sync is a file problem, not an app problem

If the library is folders and files, syncing it is already solved — by iCloud Drive, Dropbox, OneDrive, Syncthing, WebDAV, a NAS, or rsync. Put the library folder inside whichever one you already pay for and every device sees the same library, with no export, no proprietary bridge, and no per-device import.

This is the practical dividend of rules 1–3. A database has to be migrated between machines; a folder just is on both.

Rule 6: 3-2-1, and test it once

Three copies, on two kinds of media, one of them somewhere else. For a film scanner that is usually: the working library on your computer, a mirror on an external drive, and a cloud copy.

Then, once, actually restore something. An untested backup is a belief, not a backup.

What this looks like in practice

This is exactly how Winder stores a library, because we could not find a good argument for anything else:

Winder Library/
  library.json                ← format marker
  settings.json               ← scan + output settings
  albums.json                 ← album labels
  Rome, May '26/
    roll.json                 ← camera, lens, film, scanner
    WDR-260504-0001-A.jpg
    WDR-260504-0001-A.json    ← date, place, albums, favourite
  .trash/

Every file in that tree is documented, key by key, in the library format reference — not as a courtesy, but because a format nobody can read is a format nobody can leave.

If your scans are still stuck two-to-a-file from a half-frame roll, that comes first: how to split half-frame scans.

Frequently asked questions

Can I do this with Lightroom or Apple Photos?

You can use them as viewers over a folder library, and many people do. What to avoid is letting them become the only place your organisation exists — keywords and albums held solely in a catalog leave with the catalog. If you work in Lightroom, write XMP sidecars and keep the folder structure meaningful.

JPEG or TIFF from the lab?

Keep whatever the lab gives you at the highest quality you paid for, then work from that. A TIFF is the better master if you plan to edit heavily; a high-resolution JPEG is fine for everything else and a fraction of the size. What matters more is not re-saving the same JPEG repeatedly — every save costs a little quality.

How much space does a roll take?

A 36-exposure half-frame roll at high-resolution scan: roughly 300–600MB as JPEGs, several gigabytes as TIFFs. A decade of enthusiastic shooting still fits on one modest external drive.

Should I keep the original un-split scans?

Yes. They are the closest digital thing to your negatives, and re-splitting from an original costs nothing while re-scanning costs a trip to the lab. Keep them in their own folder, out of the way of the library proper.

What about the negatives themselves?

Archival sleeves, a binder, somewhere dark and dry, away from the loft and the basement. Every digital rule above is a copy of something; the negative is the original.

WorkflowLibrary

Keep reading