How a user asking for "no background" led us to a checkerboard hallucination, a 60-line chroma keyer, and a feature that ships real alpha PNGs — with zero extra models.
A user of PulseBook — our AI picture-book studio — typed a perfectly reasonable request into the refine box:
"Make the background transparent"
The model obliged. Sort of. It painted a gray-and-white checkerboard pattern into the image. Pixels, arranged to look like the Photoshop transparency grid, baked into a JPEG.
If you've never seen this failure mode, it's genuinely funny the first time. The model has seen millions of screenshots of image editors, where "transparent" looks like a checkerboard. So when you ask for transparent, it draws you a checkerboard. It's the pixel-space equivalent of a cargo cult: all the appearance of transparency, none of the substance.
The second time — when it's a paying customer trying to make chess-piece stickers for a children's book — it's less funny. So we fixed it properly.
Why models don't do this reliably
Two hard constraints, one stacked on the other:
- Typical image generation models output opaque pixels. There is no alpha channel in the output tensor, so the model has no way to say "nothing here" — every pixel gets a color. Users struggle with this constantly, and asking harder doesn't help; the model just paints a better-looking imitation of transparency.
- Most pipelines (ours included) stored JPEGs. JPEG has no alpha channel either, so even a hypothetical alpha-capable model would have had its transparency flattened at upload.
No amount of prompt engineering escapes constraint #1. This needs post-processing.
The obvious answer we didn't pick
The standard 2026 solution is a background-removal model: BiRefNet, rembg, SAM-based matting. They're good. We even have a fal.ai key wired into the stack already.
But we asked a simpler question first: why segment a background we fully control?
We're not removing a background from a photo someone took. We're generating the image. We choose what the background is. So make it a green screen:
- Detect that the user wants transparency
- Generate the image on a flat, saturated, single-color backdrop
- Delete every pixel of that color
- Ship a PNG with real alpha
Film has been doing this since the 1930s. It's deterministic, it costs nothing per image, it runs in ~100ms of CPU, and there's no second model to host, pay for, or debug.
What actually happened when we built it
The prototype worked on the first try — wooden chess pieces on flat magenta, keyed out clean. Then the real-world runs taught us four lessons that turned a naive color-replace into a proper keyer.
Lesson 1: The model doesn't reliably hit a hex code. We asked for #FF00FF. We got rgb(209,35,172). Same idea, wildly different number — a 100-unit miss in RGB space. If your keyer targets the requested color, it removes nothing. Ours samples the median color of the image's border ring and keys against what's actually there, not what we asked for.
Lesson 2: Flood fill misses the holes. Our first keyer flood-filled from the image borders — safe, because only the connected background disappears. Then we pictured a character with hands on hips. The triangular gaps between arms and body aren't connected to the border. They'd stay solid magenta forever. We switched to global color-distance keying: every pixel close to the sampled background color goes, connected or not. The arms-akimbo test passed.
Lesson 3: Fur is wide. Soft edges — watercolor washes, fluffy tails — blend with the background over 15–20 pixels at 2048px resolution. Our first despill pass only treated a 1px boundary, and the result had a radioactive green halo. The fix is a two-pass chamfer distance transform: every pixel knows how far it is from the background, and the soft-alpha ramp plus color-spill removal covers the full blend zone, scaled to resolution.
Lesson 4: Put the instruction where the model actually listens. For edits (refine an existing image), we initially injected the chroma-screen requirement into the system instruction and stripped the user's "transparent" wording. The model ignored it — twice — because edit prompts are built to obey the user's request surgically and change nothing else. The chroma instruction has to BE the user request: "Replace the entire background with one single flat solid green screen. Change nothing else." After that, compliance was immediate: the model handed us rgb(17,248,9) wall-to-wall.
The guardrails that make it shippable
A feature like this lives or dies on the failure path. Two deterministic gates run before we accept any keyed image:
- Color-family check: the sampled border must actually be magenta-like (R and B dominating G) or green-like. If the model ignored the chroma instruction and painted a scene, we know immediately.
- Flatness check: at least 80% of the border ring must sit close to the sampled median. (Not 95% — the subject's feet are allowed to touch the frame.)
Gate fails → regenerate once → fail again → the user gets an honest error instead of a half-keyed mess. During testing, the gates caught a real non-compliant generation on their first day of existence. Guardrails that fire in week one are guardrails that were worth building.
Two more details that matter in practice:
- Adaptive key color. Magenta is the default because children's books almost never contain saturated magenta. But if the prompt or book palette mentions pink, fuchsia, or purple, we switch the screen to pure green. A regex, not a model.
- Multilingual detection with a confirmation modal. "Transparent background", "przezroczyste tło", "Hintergrund entfernen", "прозрачный фон" — ten languages, diacritic-folded stem matching, so declensions match too. Detection is deliberately loose because a modal confirms intent: "AI can't draw transparency — want us to generate on a chroma screen and cut it out for real?" False positives cost one dismissed dialog. False negatives cost nothing — the user just gets today's behavior. (One tests-earned scar:
\win JavaScript regex never matches Cyrillic, and Unicode NFD-folding quietly turns й into и. Budget an hour for that.)
The scoreboard
| Background-removal model | Chroma key | |
|---|---|---|
| Marginal cost | ~$0.002–0.01/image | $0 |
| Latency | 1–2s GPU | ~100ms CPU |
| New infrastructure | model hosting or API dependency | none |
| Determinism | model-dependent | fully deterministic |
| Fails how? | silently, weirdly | loudly, at a named gate |
The whole keyer is about 60 lines of TypeScript on top of sharp: sample, gate, key, ramp, despill. The rest of the feature is a dictionary, a modal, and one flag threaded through the pipeline.
The takeaway
When an AI model doesn't do something reliably, the reflex is to reach for another AI model. Sometimes that's right. But when you control the generation, you can often set up the problem so that boring, deterministic, forty-year-old techniques solve it perfectly — and then you get to keep determinism, zero marginal cost, and failure modes you can name.
The model paints the green screen. Math does the rest.
PulseBook turns your stories into illustrated picture books — and now it makes stickers, too. pulsebook.io