Platform rebuild · applied AI · 2026

A searchable photo catalog for film-location scouting

Rebuilt a 2009-era location-scouting application: public search and a map over 802 Los Angeles–area locations and 39,754 photographs, tagged on upload by self-hosted vision models and reviewed by a person.

Organization
FilmLA
Year
2026
88.8%
image tagger hit rate, up from 30%
~0.8 s
per photo on CPU, down from 24 s
62
agencies manage their own listings
2,800+
automated tests

Results

  • Public search, no account needed.
  • End-to-end browser tests run in Playwright.
  • The hit rate counts a photo when its suggestions include its photo set’s named concept.

My role

Built the application, its tagging pipeline and its handoff documentation.

Stack

  • Python
  • FastAPI
  • PostgreSQL
  • PostGIS
  • pgvector
  • Redis job queue
  • React
  • TypeScript
  • Object storage (S3 API)
  • SigLIP 2
  • RAM++
  • llama.cpp
  • Docker Compose
  • Playwright

Before and after

Before: the old search, a flat list of 87 feature checkboxes with no counts After: the new catalog, 422 tags in nine groups, each with a live count Before After
Finding places. Left: the old search, a flat list of 87 feature checkboxes with no counts. Right: the new catalog, 422 tags in nine groups, each with a live count.

Before: the public site as it runs today, captured October 2026. After: the rebuild. Contact details blurred.

Why it’s better

  • Search that matches. On the old site a keyword search for “park” returns 632 results, mostly schools, ten to a page across 64 pages. The new search turns a scene description into tags and shows how many locations match before you commit.
  • Filters with counts. 87 unordered checkboxes became 422 tags in nine groups, each showing how many locations it would return.
  • The whole catalog on the map. The old map plots only the ten results on the current page. The new one shows every location and lists what’s in view.
  • Photos tagged as they arrive. The old site files each photograph under a feature someone picked. Self-hosted vision models now suggest tags on upload, and a person approves each one.
  • Similar locations. New: rank places by shared tags, distance or visual likeness, with the evidence shown.

What it does

Productions look for places to film by what a place looks like. The catalog answers that three ways: a plain-language scene description that resolves to tags, tag filters with counts, and a searchable index with live result counts. One search box also takes an address and finds catalog locations on that street first.

Browsing the catalog: every location with its photo sets and filters by category.
Browsing the catalog: every location with its photo sets and filters by category.

Each location has its own page with photographs, a description and a map, and similar locations rank on one signal at a time.

The catalog on the map.
The catalog on the map.
Similar locations, ranked by shared tags, with what each one shares and lacks.
Similar locations, ranked by shared tags, with what each one shares and lacks.

How photographs get tagged

  • On arrival, a CPU image tagger (RAM++) ranks the controlled vocabulary for each photograph.
  • A vision language model (Qwen3-VL, served locally by llama.cpp) looks at the photograph again and re-ranks that short list.
  • Colors are measured from the pixels, not guessed by a model.
  • SigLIP 2 embeddings, stored in PostgreSQL with pgvector, power semantic search and visual similarity.
  • Suggestions land in a review queue. Nightly jobs propose vocabulary merges and judge new words, and a person approves each change.

Every model is self-hosted, so no photograph or search is sent to a third-party AI service.

How it runs

The main stack is Docker Compose: the API, a job worker on Redis, PostgreSQL with PostGIS and pgvector, object storage for the photographs and their resized copies, the web front end and the two model services. The language model runs as a separate stack that the worker starts on demand, on GPU or CPU by setting. Schema changes go through versioned migrations, and the handoff includes a user guide, an operations runbook and a record of design decisions.