The measurement
Does the seam hold?
Lunar Canoe's continuity model rests on one claim: if you pin an authored still to the boundary between two shots, the generated clip really will land on that frame — closely enough that the cut is invisible and the earlier shot can be re-rolled without disturbing the later one. That is a testable claim, so we tested it before building on it.
Method
Three iPhone photographs of the same plush bear — frontal on a couch, then perched on a pillow, then in a different room — centre-cropped to 1920 × 1080. Photographs, not synthetic renders, because a synthetic pair flatters the model.
For each configuration we requested a clip conditioned on the first still and, where the mode supports it, targeted at the second. We then extracted the clip's actual first and last frames and compared each to the still it was supposed to match. Both images are reduced to 64 × 64 greyscale, and we report two numbers:
- MAD% — mean absolute pixel difference. 0% is identical.
- dHash — Hamming distance between 64-bit difference hashes. 0 is identical, ≤ 5 is a near-duplicate, ≥ 15 is clearly a different image.
Every configuration ran twice. The control is still #1 against still #2 on the same scale, which is the honest yardstick: it tells you what a real pose change measures, so that a small number elsewhere means something.
Results
Seam error is the generated last frame against the authored still it was aimed at, averaged over both runs. Cost is our provider cost per clip at the time of the run, not a retail price.
| Configuration | Length | Seam error MAD% / dHash | Latency | Cost/clip |
|---|---|---|---|---|
| Omni Flash · first + last + 3 references | 5 s | 0.7% / 0 | 45–49 s | $0.52 |
| Most faithful configuration measured, and the only one that carries identity references through a pinned seam. The default. | ||||
| Omni Flash · first + last | 5 s | 0.8% / 1 | 37–48 s | $0.51 |
| Identical across both runs. | ||||
| Omni Flash · first + last | 8 s | 0.9% / 0 | 46–50 s | $0.82 |
| Longer clips do not loosen the endpoint on Omni. | ||||
| Veo 3.1 Fast · first + last | 8 s | 1.3% / 0 | ~65 s | $0.64 |
| As faithful on the seam as full Veo 3.1 at 40% of the cost. Mute, and drops reference images. | ||||
| Veo 3.1 · first + last | 8 s | 1.5% / 0 | 64–75 s | $1.60 |
| Fine, and expensive. | ||||
| Veo 3.1 · first + last | 4 s | 5.5% / 4.5 | ~54 s | $0.80 |
| Visibly loose. The app refuses this combination on a pinned seam rather than taking your money for it. | ||||
| Control · two genuinely different stills | — | 16.6% / 16 | — | — |
| The pose change the model had to bridge. This is what 'different' measures on this scale. | ||||
What it means
Across 28 clips and about $27 of generation, the shared-boundary-still design holds on both providers: endpoint error of at most 1.5% MAD and a hash distance of at most 1, against a pose change measuring 16.6% and 16. An order of magnitude of headroom.
First-frame conditioning is effectively pixel-exact everywhere (0.2% on Veo). The interesting failure is the Veo 3.1 four-second case: it treats the target frame as a suggestion rather than a constraint and drifts to 5.5%, then snaps back to 1.5% at eight seconds. That asymmetry is why the app carries seam rules — a pinned shot renders at five seconds or more on Omni, or exactly eight on Veo, and asking for anything else is rejected at authoring time rather than after you have paid for it.
We also learned what the product cannot promise. Veo rejects reference images and endpoint images together, so on Veo a pinned seam costs you character locking; Omni accepts both, which is why it is the default. These are the constraints the capability model in the app encodes, and they are the reason it will sometimes tell you no.
Figures on this page come from our own instrumented runs on Google Vertex
AI, dated 30 August 2026, using gemini-omni-1.1-flash-preview, veo-3.1-generate-001 and veo-3.1-fast-generate-001. Provider models, prices and behaviour change; we will re-run and
re-publish rather than quietly leaving old numbers up.