How the seam detector is tested

A seam detector that is right most of the time is only useful if you know when it is not. So it is tested on captures where the right answer is known, and the results are published here — including the cases where it fails.

What is being tested

The long-screenshot tool rebuilds one tall page from scrolling captures. For each pair of consecutive captures it has to answer one question: how many rows at the top of the second repeat the bottom of the first? It first finds the status bar and navigation bar that sit still in every capture, then slides a strip of the second capture down the first and scores each position by normalised cross-correlation. It reports the best position, a score, and whether a second position scored almost as well — in which case it asks you to look rather than guessing.

The test builds pages whose overlaps are known exactly, cuts them into 6 captures, feeds them to that same detector — the identical code that runs in your browser — and compares its answer with the truth. Each case is 20 different pages, so 100 seams. The pages are generated from a fixed seed, so anyone running npm run bench:seams in the site’s source gets the same table.

The results

Exact means within one row of the true overlap in the detector’s own summary of the capture, which is about two pixels on a phone screenshot. Marked for a look means the tool would flag the seam as unsure or ambiguous. Wrong, not marked is the number that matters most: a seam more than four rows off that the tool would have accepted without telling you. Across all 900 seams it is 0. Run on 2026-10-31.

Where it fails, and why

Chats and tables that repeat themselves. When the same exchange or the same row appears again and again, many positions match perfectly and nothing in the pixels says which one is right. The detector gets these wrong — and marks every one of them, which is the behaviour it is built for. The fix is yours: open the seam, find a line that only appears once, and drag.

Captures whose fixed bars changed. The status and navigation bars are recognised because they are the same in every capture. When the phone dimmed part way through, or the captures were saved as JPEG so the bars carry compression noise, the bars no longer match, are not set aside, and the matcher then tries to align a status bar with page content and fails. Again every seam is marked, but none is right. Take screenshots as PNG with auto-brightness off, or crop the bars off each capture before stitching. The same dimming without any fixed bars is handled — the matcher itself is not thrown by brightness.

Fixed this month. The first run of this benchmark found that overlaps under about a tenth of a screen were never found and eight of a hundred came back confidently wrong. The search window ended too early; it now runs to the bottom bar, and the small-overlap case scores as shown above.

What the benchmark does not measure

The captures are generated directly as the 48-column greyscale summary the tool builds from each picture after the browser shrinks it, so the browser’s own resizing is not part of the test. Real pages also contain video, sticky headers that change as you scroll, and content that moves between captures; the tool cannot stitch those cleanly and the benchmark does not pretend to. The pages are synthetic text and picture blocks, not screenshots of real apps.

These are results on synthetic captures with known answers, not a promise about every screenshot. A marked seam is a request to look, and a seam that looks wrong can always be dragged into place by hand.