What the Pinefold image can establish
Pinefold is the fictional two-piece desk stand from our product-video guide. Its front-biased source image shows a teal upright, coral base, two small white circles near the left edges, a lower oval opening, and one central join. The image does not reveal whether the circles are holes or printed marks. Check their visible shape and position without assigning them a physical construction.
The requested right-side view is partly invented by each model. With one source image, you can check whether a panel appears or the join changes during the turn, but you cannot declare the unseen side geometrically correct. When the camera hides a circle or the oval, record it as not visible and inspect it again after the return to front. A verified second view would allow a separate side-accuracy test; adding it to just one model would change this baseline.
Use the same reference role and shot plan
Use one Pinefold PNG and request a portrait 720p video targeting 10 seconds. Grok and Seedance expose a duration field for 10 seconds. The Gemini Omni API guide documents portrait ratio and 720p resolution, but its examples do not show a generation-duration field; put 10 seconds in the prompt and record the length actually returned. A Gemini clip of a different length is a timing mismatch, even if the object looks sound. Keep app runs separate from API runs because an app may expose a different set of controls.
Create a 10-second vertical product video guided by the supplied Pinefold image. Keep one assembled two-piece stand on a plain light studio surface. From 0 to about 3 seconds, show the front with a slow push in. Cut to a shallow right-side view until about 7 seconds, then cut back to the front and hold. Preserve the teal upright, coral base, two small white circular features, lower oval opening, and one central join wherever they are visible. Do not add a hand, phone, label, logo, or extra part. No dialogue or music.Send that prompt once per generation. The small provider-specific media tag identifies which image it refers to; it does not add a second visual reference. These are request-body shapes from provider documentation, with placeholders for the same image and prompt. They have not been submitted for this article.
Gemini Omni 1.1 Flash
{
"model": "gemini-omni-1.1-flash",
"input": [
{"type": "image", "data": "PINEFOLD_PNG_BASE64", "mime_type": "image/png"},
{"type": "text", "text": "<IMAGE_REF_0> PASTE_SHARED_PROMPT_HERE"}
],
"response_format": {"type": "video", "aspect_ratio": "9:16", "resolution": "720p"}
}Google describes <IMAGE_REF_0> as a reference role, while <FIRST_FRAME> asks for a starting-frame pin. If the model treats the image as the literal opening frame despite the prompt, note that behavior before trying the documented generation_config.video_config.task value reference_to_video in a separately labeled run. In REST output, extract the MP4 data from the model_output step; the SDK also exposes output_video. Google's input, role, task, and response examples show these fields.
Grok Imagine Video 1.5
{
"model": "grok-imagine-video-1.5",
"prompt": "<IMAGE_1> PASTE_SHARED_PROMPT_HERE",
"reference_images": [{"url": "PINEFOLD_PNG_PUBLIC_URL"}],
"duration": 10,
"aspect_ratio": "9:16",
"resolution": "720p"
}Post to /v1/videos/generations, retain the returned request_id, and poll /v1/videos/{request_id} until done, failed, or expired. Save the completed video locally. Use reference_images here: xAI's separate image field pins the first frame, changing what the test measures. xAI's reference-to-video examples show the request and polling flow.
Seedance 2.5 through BytePlus LAS
{
"model": "dreamina-seedance-2-5-260628",
"content": [
{"type": "text", "text": "PASTE_SHARED_PROMPT_HERE"},
{"type": "image_url", "image_url": {"url": "PINEFOLD_PNG_PUBLIC_URL"}, "role": "reference_image"}
],
"duration": 10,
"ratio": "9:16",
"resolution": "720p",
"generate_audio": false
}Post to the /api/v1/contents/generations/tasks endpoint for your LAS region, then query that task path with its returned id. Keep role: reference_image; first-frame mode is a different input. The task response reports actual duration, ratio, resolution, audio setting, and status, so retain it with the MP4. A public image URL must remain reachable while the task runs. BytePlus's model, parameter, and task documentation provides these fields and the region caveat.
For every attempt, save the submitted body with credentials removed, source-image checksum, model ID, returned request or task ID, status, MP4, and actual duration and dimensions. A rejected request or missing video stays in the record; it is not a continuity score. If a provider changes or rejects a setting, record the accepted value before comparing clips.
Review the turn, not just the opening frame
Make three independent attempts per model with the same one-image setup, keeping every completion and failure. Three clips give a small exploratory check; they cannot establish a stable failure rate. Inspect each finished clip at the opening, immediately before and after both cuts, halfway through the angled view, and at the settled ending. Write down the actual cut times rather than assuming they landed at 3 and 7 seconds.
| Checkpoint in each MP4 | Time to fill in | What to record against the source |
|---|---|---|
| Opening front | ___ s | Two assembled parts; teal upright; coral base; two white circles; lower oval; one join |
| Before / after first cut | ___ / ___ s | Which features remain visible, become hidden, move, or change |
| Middle of right-side view | ___ s | Extra panel or part; changed join; newly visible side details, marked unverified against the source |
| Before / after return cut | ___ / ___ s | Whether the same assembled stand returns without a color or feature swap |
| Settled front | ___ s | Recheck both circles, oval, join, parts, and colors against the opening and source |
Use same, changed, or not visible for each feature at each checkpoint. Call a visible feature failure when a circle shifts or disappears on the returning front, the oval is replaced, the join splits, the part colors swap, or an extra part persists. An obscured feature is not a failure until a comparable view reveals it. Record shot completion separately: whether the first front, side turn, second cut, and return front actually occur, plus the MP4's real duration. A static front view can preserve identity while missing the requested shot.
Report counts only after filling the sheet: for each model, return-front feature pass ___ / 3 completed clips and shot-plan pass ___ / 3 completed clips, alongside the number of failed or missing generations. If only two clips complete, use ___ / 2 completed clips and report the third failure separately. Do not turn a blank example into an observed result or combine rejected jobs with visual failures.
Investigate a specific failure with a separate run
If the returned front loses Pinefold's circles or oval, try a labeled endpoint-control run using the same source as both first and last frame. Gemini documents <FIRST_FRAME> and <LAST_FRAME> on one image; xAI uses image with last_frame; BytePlus lists first/last-frame input. Compare the middle of this new clip with its own pinned endpoints. A correct final frame alone does not clear a new panel at second 5. Google, xAI, and BytePlus document these separate modes.
For a defect confined to one segment, Gemini supports an edit linked by previous_interaction_id, and ByteDance describes targeted editing in Seedance 2.5. Save the original and edited MP4s. Inspect both cuts again after the fix, because correcting the side view would be of little use if the returned front changes. These are documented controls, not a claim that either provider repaired Pinefold.
