feat(intake): remove the background from submitted photos #281

New Issue

2026-09-03T10:17:19-05:00

bermudalamb commented

2026-09-03 10:17:19 -05:00

Design: docs/superpowers/specs/2026-09-03-background-removal-design.md
Engine evaluation: docs/ops/image-background-removal-stack.md

A consignor photographs an item on a kitchen table. The shop wants it on a clean transparent ground, consistent with the rest of the catalogue.

Two entry points over one shared implementation:

The submitter's page (/submit/:token) gets a checkbox, ticked by default. It records an intent; the drafting worker acts on it alongside the AI draft.
The review queue gets a control on each photo, with Restore original where a photo has already been cut out.

The line that matters most

model=u2net is sent on every request, always. The sidecar image's default is bria-rmbg, and BRIA's RMBG models are licensed non-commercial — this is a shop. The default is reached by simply not specifying one, so it is a silent licensing problem that produces a perfectly good image. u2net is Apache-2.0, and measured ten times faster (1.1–2.3 s against 14–20 s) at a sixth the size. A test asserts the parameter is present, because nothing in the output would reveal its absence.

Why the submitter's tick is an intent rather than work done during upload

Doing it inline would make the submitter wait, put a CPU-heavy model run in a path anyone holding a link can trigger — the surface #227 exists to bound — and force a choice, when the sidecar is unreachable, between failing their submission and silently ignoring what they asked for. Recording the intent means the submission always succeeds and keeps its original photo.

What cannot be lost

The original is never destroyed. Removal writes a new file and records where the original went; restoring swaps back. The submitter's photos are often the only copy of an item no longer in their hands, which is why Discard deletes nothing either — and background removal is exactly the operation that produces occasional bad results on an unusual object.

Every failure path leaves the photo as it was: an unset REMBG_URL, an unreachable sidecar, a timeout, a non-image response. Removal never fails a submission and never fails a draft.

Known unknown

Quality on a real photograph. The engine evaluation used a generated rectangle on a flat ground, which says nothing about a chipped vase on a patterned rug. The first real submission is the test; the per-photo control and Restore are what make a poor result survivable rather than something to prevent.

Part of #220's follow-on work.

**Design:** `docs/superpowers/specs/2026-09-03-background-removal-design.md` **Engine evaluation:** `docs/ops/image-background-removal-stack.md` A consignor photographs an item on a kitchen table. The shop wants it on a clean transparent ground, consistent with the rest of the catalogue. Two entry points over one shared implementation: - **The submitter's page** (`/submit/:token`) gets a checkbox, **ticked by default**. It records an intent; the drafting worker acts on it alongside the AI draft. - **The review queue** gets a control on each photo, with **Restore original** where a photo has already been cut out. ## The line that matters most `model=u2net` is sent on every request, always. The sidecar image's default is `bria-rmbg`, and BRIA's RMBG models are licensed **non-commercial** — this is a shop. The default is reached by simply not specifying one, so it is a silent licensing problem that produces a perfectly good image. `u2net` is Apache-2.0, and measured ten times faster (1.1–2.3 s against 14–20 s) at a sixth the size. A test asserts the parameter is present, because nothing in the output would reveal its absence. ## Why the submitter's tick is an intent rather than work done during upload Doing it inline would make the submitter wait, put a CPU-heavy model run in a path anyone holding a link can trigger — the surface #227 exists to bound — and force a choice, when the sidecar is unreachable, between failing their submission and silently ignoring what they asked for. Recording the intent means the submission always succeeds and keeps its original photo. ## What cannot be lost The original is never destroyed. Removal writes a new file and records where the original went; restoring swaps back. The submitter's photos are often the only copy of an item no longer in their hands, which is why Discard deletes nothing either — and background removal is exactly the operation that produces occasional bad results on an unusual object. Every failure path leaves the photo as it was: an unset `REMBG_URL`, an unreachable sidecar, a timeout, a non-image response. Removal never fails a submission and never fails a draft. ## Known unknown Quality on a real photograph. The engine evaluation used a generated rectangle on a flat ground, which says nothing about a chipped vase on a patterned rug. The first real submission is the test; the per-photo control and Restore are what make a poor result survivable rather than something to prevent. Part of #220's follow-on work.

bermudalamb referenced this issue from a commit

2026-09-03 10:49:58 -05:00

docs(intake): design background removal for submitted photos (#281)

bermudalamb referenced this issue

2026-09-03 10:51:11 -05:00

docs(intake): design background removal for submitted photos (#281) #283

bermudalamb referenced this issue from a commit

2026-09-03 10:52:03 -05:00

docs(intake): design background removal for submitted photos (#281)

bermudalamb referenced this issue from a commit

2026-09-03 10:52:05 -05:00

Merge pull request 'docs(intake): design background removal for submitted photos (#281)' (#283) from feature/281-background-removal into main