Pelagic Video Fidelity

Headline finding: the fix that actually scales isn't a cleverer prompt — it's simpler than that. Feed the model real, undegraded catalog photos instead of the padded/AI-outpainted stack production has been building, and a fully generic prompt (no per-product authoring at all) gets every headline defect fixed. A hand-written, per-product prompt was tried first and looked like the answer — it wasn't. See Section 5.

189 "video ads" were actually 18 real generations plus 171 derives

A derive is a free crop/retitle of an already-existing master into a different aspect ratio — it never generates new pixels. Splitting the two out:

Worse: 44 derives of a passing master still failed, and 9 derives of a failing master passed. Production QC on a derive is largely noise — the ~20% headline number was a derive statistic, not a generation-quality statistic.

Even the real 62% wasn't the full story

Production's own quality check judges each video against the reference stack it was given — which is itself padded, cropped, or AI-outpainted, not the real product photo. Judging the same 14 masters directly against the native catalog photograph instead:

A. A live money leak — refinedProducts missing from the catalog query

The code that decides "can we free-crop this reference, or do we have to pay for an AI outpaint" needs YOLO-detected product boxes. The query loading sibling reference images for a video simply never requested that field. Every auto-assembled sibling was forced onto the paid path regardless of whether a free crop was possible.

Found a teammate had already fixed this in a copy of the code that isn't the one actually running in production. Fixed in the live renderer, deployed.

B. Seed images padded at the wrong scale

The product-only seed image was padded to the video's delivery resolution (as small as 720×720 for the product itself) instead of the source photo's own resolution — throwing away most of the real detail before the video model ever saw it.

Fixed — pad now derives its canvas from the source image, preserving up to 3× more real pixels of the product.

C. The "zoom to detail" instruction was the single biggest source of invented defects

Counting every defect found across the 14-ad blind pass by the video timestamp it appeared at: the frame at the midpoint — exactly where the prompt says "slow zoom toward the most distinctive product detail" — carried 6 of 11 total defects. The zoom wasn't panning across real pixels; it was cutting to a newly generated close-up, and that's where the model invented things.

Partially addressed — see the real fix in Section 5, which supersedes the original "just remove the zoom" attempt.

What was verified, directly against Atlas's own API

The exact same combination that had been generating successfully all day — duration=10, aspect_ratio=9:16 — started returning:

HTTP 500 → "All channels failed. Last error: HTTP 422:
The model 【omni_flash-10s-portrait】 does not exist"

Confirmed by fetching the byte hash of the "new" video and finding it identical to the pre-outage file — Atlas never generated anything new, and critically, never billed for it either. One real generation that landed during the same window (a different ad, retried automatically) proved the persist logic itself was fine — when Atlas returns a real video, it saves correctly. The failure was isolated to one internal Atlas routing channel for that specific duration+aspect combination, confirmed by direct API calls, not inferred.

A retry policy was also caught and stopped mid-flight — it was about to auto-resubmit two more ads into the same dead channel.

Reference images actually supplied

Same three-image stack the production pipeline builds for every ad — shown here so the comparisons below are legible against real inputs, not assumed ones.

Three arms, same product, same original prompt

Same product, same prompt, three genuinely different outcomes — proof that the model, not just the reference prep, is a real variable in fidelity.

Why the hand-written approach hit a real wall

The sleeve print refused to clear no matter how the prompt was worded — the block explicitly said "forearms otherwise blank" and the model still copied a stacked invented print onto the sleeve. The reason: that print was already baked into the reference photo itself — a leftover artifact from an earlier AI-outpaint step. No prompt instruction can override what the model is literally shown in a picture.

Worse, on a second product the hand-written marks were factually wrong: the block said the waistband had "NO second line," but the real catalog photo genuinely shows BUILT FOR FISHING as a second line. The manual authoring had suppressed something that was actually true.

Condition B on video — the hand-written-marks arm, degraded stack

The still above is a single frame. The full arm was four real generations, one per ad, each using a hand-written per-SKU marks block against the same padded/cropped/reframed reference stack production builds today (not the raw catalog photo). All four are the direct "before" counterpart to the Condition C clips further down this page.

Verified independently, on a fifth product

To make sure this wasn't specific to the four ads already under a microscope, the same clean-photo + generic-prompt approach was run on Leaderman — a product that had already passed under the old pipeline, used here as a check that the new approach doesn't regress a product that was already fine.

Provenance

Prompt

generic CORE — native-generic/CORE.txt, 1159 UTF-8 bytes, sha256 67899bcf…. request-shape.json notes no PRODUCT MARKS, no <IMAGE_REF_N>.

Images

3 raw catalog fileUrl — product_only / on_model / detail. Not the padded/reframe stack used elsewhere for this ad.

Model

gemini-omni-1.1-flash · reference_to_video · 9:16 · resolution not stated in the catalog for this row (measured: 720×1280, 10.00s)

Source

Leaderman ad 6a986320eea5b7d839449c89 · post-leaderman-native-generic.py

Mostly clean, with one honest miss worth keeping in the record: the waistband and construction came through perfectly, but a secondary hem tag came out with the wrong layout — the real tag reads "boxed P + fish icon, then PELAGIC below it"; the generated one swapped the order and dropped the box entirely.

Clean photos plus a generic prompt gets you most of the way there — it fixed the hardest marks on every product tested — but it isn't a guaranteed clean sweep on every secondary detail. A mark the prompt never specifically calls out can still drift.

What ships

1. Build the reference stack from real catalog originals — the plain product photo, an on-model shot, and whichever detail photo actually has the readable branding — instead of the padded/AI-outpainted derivatives used today.
2. Use the generic prompt, unchanged, for every product. No per-SKU writing.
3. Optionally, tell the model explicitly which of the three photos to trust for fine print. This turned out to be a non-issue — see below.
4. Keep hand-written marks only as a fallback, for the rare case where the reference stack is unavoidably degraded — never author them from a photo too small to actually show the real letters.

SettledDoes per-image staging require new classification? No — it's already there.

The remaining worry was real: if you want to tell the model which of the 3 photos to trust for fine print, don't you need to run a new vision pass on every catalog image first? Checked against production data: that classification already exists. Every catalog image already carries a label (plain product photo / on-model / detail shot), written once by an existing classifier and reused forever — verified directly against a real product's own 3 submitted photos, where the stored labels matched exactly what those photos show. A second existing field (extracted on-image text) already answers which photo has the readable branding.

One real caveat, also verified: on a different product, "detail" turned out to mean a fabric close-up, not a logo — so the fix reads the extracted text on the selected photo rather than trusting the label name alone. With that adjustment, no new spend is needed for this at all.

AnsweredDoes telling the model which photo to trust help?

Tried explicitly staging the three photos by role — "use this one for the wide shot, use that one for fine print" — on top of the hand-written-marks approach. It worked cleanly, but a direct side-by-side against skipping staging entirely (clean photos, no staging, no per-product marks) showed the marks were reproduced just as accurately either way. Staging is a nice-to-have, not a requirement.

AnsweredDo you need a new vision pass to know which photo is which?

No. Checked against production data: every catalog photo already carries a label (plain product photo / on-model / detail shot), written once by an existing classifier and reused forever — verified directly against a real product's own 3 submitted photos, where the stored labels matched exactly what those photos show. A second existing field (extracted on-image text) already answers which photo has the readable branding, with one caveat: "detail" sometimes means a fabric close-up, not a logo, so the fix should check the extracted text, not just the label name. Either way, this is a code change reading data that already exists — not a new cost.

All spend tracked against a $50 approved budget for this investigation; nothing close to the limit. No billable request was ever retried after a failure — every failed attempt above cost $0, confirmed directly against each provider's own settlement record. One transient (unbilled) API error was retried once, which is why the count of real generations is slightly higher than the ad count.

Root-causedThe Chubasco sleeve-text defect

The garment's marks are reflective white — legible in the product_only packshot, dark and low-contrast in on-model shots. That's also why OCR read them as HELLY HANSEN / RAINS earlier tonight: it was reading a dark, low-contrast smear, not the mark itself.

An experimental face-first reference-ranking approach dropped feed 0 — the packshot, which is production's actual seed image, and which OCRs PELAGIC correctly three times at 0.96 / 0.80 / 0.83 confidence — in favor of three on-model shots where the same text is barely legible. Production's real stack renders PELAGIC correctly on the first try with the plain generic prompt. The tagged-crop "fix" attempted earlier tonight was solving a problem the face-first ranking itself had created. Stated plainly because it's the most useful negative result of the night: the fix for a self-inflicted defect is to stop inflicting it, not to compensate for it with more prompt machinery.

Shipped — live in productionThe harm was text-specific

Knockdown (no printed wordmark on the garment) was fine under the face-first ranking; Chubasco (fine reflective text) broke. So the ranking itself wasn't wrong everywhere — only where a real mark depended on the packshot's contrast.

Resolution: protect slot 0 for product_only, and apply the face preference only to slots 1–2. That still yields a person in the majority of frames (6 of 10 measured), and a packshot-only stack generates a person anyway — Rod Holder invented a shirtless model from two packshots with no on-model reference at all. This shipped today and is live in production.

OCR is unreliable in three distinct modes

All three observed on real Pelagic garments tonight, not synthetic cases:

• Competitor hallucination — HUK at 0.98 confidence, PATAGONIA at 0.98, plus AFTCO, BILLABONG, RVCA, REEF, SALT LIFE, and RIP CURL on garments that carry none of those marks.
• Sanitisation — AHI PURSUIT at 0.96 confidence for the genuine printed text "Ahi Pussy."
• Misclassification — BUILT FOR FISHING typed as general rather than as text.

Any logic keyed on Media.text[].type or .content inherits all three failure modes. That's the direct reason the seed-text prompt machinery is being removed rather than patched — see below.

A live prompt contradiction, deleted today

OMNI_DIRECTIVES.noText told the model that on-product text was "fine to show," while a separate seed-text guard inside the same prompt told it to "not read, reproduce, extend, or generate more of it." Both instructions shipped in every prompt whenever a seed image had any OCR'd text on it — a direct contradiction the model had to arbitrate on its own, silently, on every single generation. Removed and deployed today.

Ships dark today — pending validationInput-side degradation is being removed from the video path

Three sources of input degradation are being taken out of the reference stack the video model sees: the billable AI outpaint (google/nano-banana-2/edit-developer, $0.08/ref), the YOLO/DINO-driven reframe strategy, and Cloudinary's c_crop/c_pad transforms.

Precisely scoped: this is input only. The output-side crop that derives the Meta 1:1 / 4:5 / Reels and PMax 1:1 deliverables from one paid master is a money invariant and stays exactly as it is — nothing about how a finished video gets re-cropped for delivery changes. This ships dark today, pending a production-route validation pass.

Gemini economics, both measured at matched 1080p

Atlas: $0.90/master settled. Gemini direct: $1.0351/master (about 15% more) — both at 1080p.

1080p bills identically to 720p — 57,920 video tokens for a 10-second clip either way — and the 1080p output was ffprobe-confirmed as genuinely 1080×1920, not a silently downgraded 720p upscaled in the response metadata. So going to 1080p costs nothing extra.

Measured wall-clock, submit to terminal state, across three runs: 46s / 60s / 80.6s.

1. Land the three pipeline fixes (money leak, pad scale, the reframe cache reconciliation) — already written and verified, not yet merged to trunk.
2. Wire the real reference-selection path to catalog originals, not the padded/outpainted stack — this is the change that actually matters, confirmed across five products so far. A second round on five more products, using production's real selection logic, is in progress now to confirm this holds at broader scale.
3. Retire the per-product hand-written marks approach as the default — keep it only as a fallback for the rare case where a clean reference genuinely isn't available.
4. Build the minimal testing harness so this kind of investigation doesn't require hand-rolling a simulation every time — a true dry-run mode that shows exactly what production would submit without paying for it, plus a persisted record of what was actually sent to the model on each real ad.
5. Fix the reference-preparation pipeline itself — the sleeve-print contamination came from an earlier AI-outpaint step, and switching to clean images sidesteps it here but doesn't fix the root cause for cases where a clean photo genuinely isn't available.