How we make our nonograms

A nonogram is only ever a black-and-white silhouette — no shading, no color, no interior detail. So the first step is picking a source image whose shape reads clearly at a tiny resolution: an animal, a piece of fruit, a zodiac symbol, a household object. We work from vector art (SVG), transparent PNGs, and plain photos, organized into themed asset packs, plus images pulled in through an in-app image search.

What matters at this stage isn't how pretty the image is — it's how well its outline survives being crushed down to a 15×15 or 20×20 grid. A bold, well-separated shape works. A busy scene with a lot of small overlapping parts almost never does, and we'll see why below.

The image is rasterized with a real imaging library (the same one browsers lean on for SVG), then reduced to a single black-or-white value per cell. There's no single "correct" way to do that, so the pipeline tries several: keying off the image's own transparency where it has any, off plain brightness (dark = filled), or — for a bright, colorful subject on a plain background, where brightness alone barely separates it — off color distance from the background. A light-orange fox on white is nearly white in brightness but far from it in color; the color-distance mask isolates it cleanly.

The cutoff between "filled" and "empty" is chosen automatically using Otsu's method, a standard technique that finds the brightness threshold splitting the image most cleanly into two groups. Because there's no way to know in advance which size, crop, and threshold will read best, the pipeline generates many candidate grids per image — different sizes, different thresholds — crops each to its filled content, and fits the shape to the grid's proportions so a wide crown gets a wide grid instead of being squished into a square.

A picture that looks fine to a human is not automatically a valid puzzle. A real nonogram has to be solvable from its row and column clues alone, and — crucially — it has to have exactly one solution. If two different filled patterns both satisfy every clue, the puzzle is ambiguous and unfair, because a solver following pure logic could correctly arrive at the "wrong" picture.

So every candidate is fed to a solver: it applies the same line-by-line deductions a person would, and where logic alone stalls, it falls back to an exhaustive search to count how many complete solutions exist. Any grid with zero solutions (contradictory) or more than one solution (ambiguous) is rejected on the spot. This uniqueness check is the single most important gate in the whole pipeline.

Having one solution isn't quite enough. A puzzle can be technically unique but only reachable by trial-and-error — filling a cell, following it deep into the grid, and backtracking when it contradicts. That's not solving; that's guessing, and it makes for a frustrating puzzle.

To catch this, we classify how hard each puzzle is to reason through. Puzzles that fall out from straightforward line-by-line logic are "simple." A second, well-studied tier of deduction (based on published nonogram-difficulty research by Batenburg and Kosters) handles most of the rest without any guessing. Anything that still can't be settled without trial-and-error is flagged as guessing-required — and for the everyday catalog, those are set aside rather than published.

Before any of the solving work, the pipeline also predicts whether an image is even worth trying, using two blunt but honest signals. One is separability: how cleanly the image splits into two tones at all — a muddy, low-contrast source is a bad bet at any size. The other is a detail-versus-resolution fit: an image with far more fine features than the grid has cells will just collapse into a blob.

A concrete example from our own testing: a real photo of the Eiffel Tower produced a 40×40 candidate that passed every solvability check — one unique solution, a reasonable fill ratio — but rendered as a solid rectangle. The tower's lattice detail and the clutter beneath it flattened into one undifferentiated block. Technically a valid nonogram; visually useless. Cases like that are exactly what these upfront checks, plus a human glance, are there to stop. To be clear about the limits: there is no vision model here — the pipeline never recognizes *what* is in a picture, only measures how well its shape converts. That's why the final call is still a person's.

Puzzles that clear every gate get a difficulty rating from their solving tier and shape statistics (how filled the grid is, whether the picture runs off the edges, and so on), which is what sorts them into easy, medium, and hard collections. Then a person opens the ones headed for the catalog in our grid editor, checks that the picture actually reads as what it's supposed to be, and adjusts or discards anything the automated checks waved through but shouldn't have.

It's a deliberately unglamorous process, and that's the point: the automation exists to guarantee fairness — one solution, solvable by logic — while a human guards the thing a computer can't judge, which is whether the finished picture is any good.