Skip to content

Home

Jump to bottom
Trent Bauer edited this page Jul 12, 2026 · 5 revisions

FilmCalc Wiki

FilmCalc is a lightweight, responsive, mobile-friendly web app for analog photographers to work out the true cost per photo of shooting film — and to figure out which of their labs is actually cheapest for a given roll, once push/pull fees are factored in.

Live app: https://filmcalc.trentbauer.com

What do you want to do?

What is and isn't this tool?

Mission: work out the true cost per photo of shooting film, and figure out which lab is cheapest for a given roll. A feature earns its place by serving comparing and calculating cost — not by being generally useful to film photographers, and not by being easy to bolt on.

Explicitly out of scope

This will never track:

  • what film you've put in what camera
  • what cameras you own
  • what film you own
  • how many rolls of a given film you've shot
  • a shooting log or diary — dates, locations, subjects, frame-by-frame notes
  • photos themselves — uploads, galleries, EXIF data

And it will never become:

  • an account/login system with server-side storage. Everything lives in the browser's localStorage by design (see Self-Hosting for the one exception — a self-hosted config.yaml an admin seeds, not a per-user account). A synced-across-devices account system is a different app, not an extension of this one.
  • a checkout/payment flow. "Buy" links send you to the real store's own page; FilmCalc never handles money itself.

Squarely in scope

  • Anything that makes a cost/price comparison faster, clearer, or more accurate — new views, filters, themes, tooltips, calculators (like the Expired-film speed estimator, which is about a shooting setting, not a log entry).
  • Managing the pricing data that feeds those comparisons — films, labs, bundles, service tiers, import/export.
  • Sharing or automating a calculation — e.g. the Share Link feature, or this wiki's own automation.
  • Developer/CI tooling that keeps the project healthy — workflows, security fixes, docs.

If a request doesn't clearly fall on either side

Don't guess — whether you're a human triaging an issue, or the scheduled Claude workflow deciding whether to implement a feature request:

  • Clearly out of scope (matches a bullet above, or is obviously the same idea in different words — e.g. "log which rolls I've shot this month" is shooting-log tracking by another name)? Say so and comment/close — don't implement it "just in case it's useful."
  • Genuinely ambiguous — could reasonably be read as either a cost-comparison feature or as gear/inventory tracking, or doesn't give enough detail to know what "done" looks like (which tab it belongs in, what it should actually show, whether it needs new data fields)? Ask specific clarifying questions instead of implementing or declining. A vague request deserves a conversation, not a coin flip in either direction. Naming the exact thing that's unclear (not just "can you clarify?") makes it something the requester can actually answer.

Contributing data to the project

Want to add a film stock or lab to the public presets everyone gets on first import (rather than just your own private Library)? See CONTRIBUTING.md in the repo — there's a one-click "paste a shop link into Claude" flow that writes the YAML for you.

Built With

  • Tailwind CSS — styling and responsive layout
  • js-yaml — reading and writing the YAML profile files client-side
  • Vanilla JavaScript — application logic, localStorage for saved profiles
  • nginx (Alpine) — serves the static app in the Docker image

Originally vibe coded by Google Gemini, with further features built by Claude (Anthropic).

Clone this wiki locally