What Each Image-to-Video Model Actually Requires From the Input Photo

Quick answer:a JPEG or PNG that is at least 300 pixels on each side, sits between 1:2.5 and 2.5:1 in aspect ratio, and is under 10 MB clears every published constraint on every image-to-video model we run. Past that common floor the rules diverge, and the divergence that costs people credits is not the file format. It is what happens to the aspect ratio setting once a photo is attached. Happy Horse 1.1, Kling 2.6, Seedance 1.5 Pro and Grok Imagine Video all state in their schemas that the photo's own ratio wins and the dropdown is ignored (or, on Grok, defaulted). A landscape product shot becomes a landscape ad no matter what you picked. Veo 3.1 Fast is the one model that treats aspect ratio as a real parameter and asks for a photo that already matches it. Only three models accept more than one photo as references (Happy Horse 1.1, Kling 3.0 and Seedance 2.0). Veo 3.1 Fast and Seedance 1.5 Pro take a second still only as a closing frame. The three talking-actor models need a face in frame, not a bottle. Everything below was read off the live input schemas on 4 September 2026 and cross-checked against our own dispatch code.

Why the photo, not the prompt, decides the render

Every video model in our registry except the two Sora models requires a starting image, and those two leave the Replicate bridge we call on 24 September 2026, so in practice you always supply a first frame. The model then treats that frame as ground truth. It will not widen a 4:5 product shot into 9:16 for you, it will not invent the back of the box, and on most endpoints it will not even look at the aspect ratio you selected. The prompt shapes what moves. The photo fixes what exists. On TikTok Shop that is also policy: the Seller Center requires product videos to display the physical product accurately, which TikTok Shop's AI content rules quotes in full.

That is why the hard constraints matter more than the guides that tell you to "use a clean, well-lit product photo". Clean and well-lit is taste. A 300-pixel floor, a 10 MB cap and a 1:2.5 ratio limit are rejections. And the aspect behaviour is neither: the render succeeds, you pay for it, and it is the wrong shape.

The hard constraints, per model, from the schemas

The table lists the exact endpoint our pipeline dispatches to and the constraints its published input schema states. Where a schema publishes no format, size or pixel limit, the cell says so rather than guessing. Seedance 2.0 is the one exception to the Replicate sourcing: in production it runs on BytePlus, so its row comes from BytePlus's API reference and the Replicate copy of the model is quoted only for field behaviour.

Two rows deserve a note. Veo 3.1 Fast is the endpoint we call, not the standard google/veo-3.1, and the Fast schema exposes an image and a last_frameand nothing else for stills. Google's own Veo documentation describes up to three reference images for Veo 3.1 and Veo 3.1 Fast on the Gemini API, but Replicate's google/veo-3.1-fast schema does not expose a reference_imagesfield, so through this pipeline Veo is a one-photo model. Seedance 2.0's constraints are BytePlus figures, and the 30 MB ceiling and 6,000px maximum are far looser than Kling's. That is why the common floor in the quick answer is set by Kling 3.0 and Happy Horse 1.1 rather than by Seedance.

The aspect trap, and the one model that avoids it

Read the last column again. Three schemas say, in slightly different words, that the photo overrides the setting, and a fourth makes the photo the default. Happy Horse 1.1: "When a single image is provided (image-to-video), the image's aspect ratio is used." Kling 2.6: "Aspect ratio of the video. Ignored if start_image is provided." Seedance 1.5 Pro: "Video aspect ratio. Ignored if an image is used." Grok: "For image-to-video, defaults to the input image's native aspect ratio." Kling 3.0 goes further and makes the setting conditional: "Aspect ratio. Required when not using start frame or video editing."

Our own dispatch code says the same thing from the other side. The builders for these models still pass the aspect value through, and the comment on the shared aspect helper treats a fallback value as harmless on image-to-video calls because the input image's ratio wins. That note is only strictly true for the models whose schemas say so. So a 1:1 Shopify product photo produces a square ad on Happy Horse, Kling 2.6 and Seedance 1.5, and the 9:16 you selected in the wizard was decorative. Grok is the softer case: its schema says the setting defaults to the photo's ratio, and our builder sends your pick explicitly, so treat the photo's ratio as what you will get unless the model honours the override. If you have ever wondered why a vertical campaign came back square, this is why.

Veo 3.1 Fast is different in kind, not degree. Its aspect_ratiois an enum of exactly two values, 16:9 and 9:16, and the image field says: "Input image to start generating from. Ideal images are 16:9 or 9:16 and 1280x720 or 720x1280, depending on the aspect ratio you choose." The setting is real, and the schema is telling you to pre-crop the photo to match it. Send a square photo with 9:16 selected and you are relying on the model to reconcile the two. Send a 720x1280 portrait crop and there is nothing to reconcile.

The fix is the same on every model and takes ten seconds: crop the photo to the ratio you want the ad to be, before upload. For a vertical ad that means 9:16, and for Veo specifically 720x1280 or 1280x720. The Amazon 16:9 post works the same problem in the opposite direction, where the platform demands landscape and the photo library is all portrait.

Multi-photo inputs: three models, three different grammars

A product-in-hand ad or a demo that shows the box, the bottle and the label usually needs more than one still. Only three models take more than one still as a reference, and none of them take it the same way.

• Happy Horse 1.1 has a single imagesarray: none for text-to-video, one to animate as the first frame, "or multiple images (up to 9) for reference-to-video." The prompt refers to them as "[Image 1], [Image 2], etc." With two or more images the aspect setting applies again, because there is no single frame to inherit from.
• Kling 3.0 keeps start_image and reference_imagesas separate fields. The first is the locked opening frame; the rest are "Reference images for elements, scenes, or styles", capped at "Max 7 without video, 4 with video." The prompt syntax is <<<image_1>>>, and the prompt itself is limited to 2,500 characters. Our pipeline sends the first upload as the start frame and up to six more as references.
• Seedance 2.0forces a choice. BytePlus: "Image-to-video (first frame), image-to-video (first and last frames), and omni reference-to-video (including reference images, videos, and audio) are mutually exclusive scenarios and cannot be mixed." The Replicate copy of the model says the same in its field descriptions: the first-frame image "Cannot be combined with reference images." So with one photo you get a locked first frame; with two or more you get a reference set of up to 9 and give up the frame lock. BytePlus adds that in reference mode you can name one reference image as the first frame in the prompt to get the effect indirectly, and that only the first-and-last-frame mode strictly guarantees a pixel match. Our builder makes exactly that switch at two images.

The practical consequence: if the opening frame must be your actual product shot, pixel for pixel, Kling 3.0 is the only multi-photo model that guarantees it while still taking references. On Seedance 2.0 the reference route means the model composes the first frame itself. The product demo post covers how to structure a multi-clip demo around that difference, and product-in-hand UGC covers the compositing case.

Talking-actor models: the photo is the actor

OmniHuman 1.5, VEED Fabric 1.0 and Pruna Avatar are a different category. They take a still and a voice track (through our pipeline Pruna generates its own speech from voice_script, described as "Exact words the avatar should say. Required when no audio file is uploaded.") and animate the still to match. OmniHuman's schema states the requirement plainly: "Input image containing a human subject, face or character." Pruna calls its image the "first frame". There is no aspect field on any of the three, and the output length is the audio length, which on OmniHuman is capped hard: "Duration must be less than 35 seconds. If the audio exceeds 35 seconds, an error will be generated and the generation will fail."

So a product-only photo is the wrong input here, and a photo of a person holding the product is the right one. If you need to know which of these three to pick, the lip-sync model comparison is the relevant read; this post only cares that the face is in the frame before you upload.

A pre-upload check that satisfies every row

• Export as JPEG or PNG. WebP is fine on Grok, Pruna, Happy Horse and Seedance 2.0 and refused by Kling 3.0's .jpg/.jpeg/.png list, so JPEG is the export that never needs a second thought.
• Keep both sides at 300px or more. Kling 3.0, Happy Horse 1.1 and BytePlus all publish that floor. A 1280x720 or 720x1280 file clears it and also hits Veo's stated ideal.
• Stay under 10 MB. That is the tightest published cap (Kling 3.0 and Happy Horse 1.1); BytePlus allows 30 MB, which changes nothing if you already fit the tighter one.
• Keep the ratio between 1:2.5 and 2.5:1. A very tall banner crop fails Kling 3.0, Happy Horse 1.1 and Seedance 2.0 alike. Then crop to the ratio you want the ad to be, because on most models that crop is the ad's ratio.
• For a talking actor, make sure a face is in the frame and the voice track is under 35 seconds.
• For multi-photo work, decide whether you need a locked first frame (Kling 3.0) or a reference set (Happy Horse 1.1, Seedance 2.0), and write the prompt in that model's reference syntax.

None of this is a quality tip. It is the set of rules the endpoints enforce, or silently apply, and the reason it belongs in front of the prompt-writing step is that a successful render from the wrong photo is billed at full price. On our catalogue the three most common picks land between 245 and 315 credits per clip, and a clip that came back the wrong shape costs the same as one that came back right. If you are writing the Veo prompt next, the six-part Veo 3.1 prompt shape assumes the photo is already right.

Sources

• Replicate, google/veo-3.1-fast input schema (image, last_frame, aspect_ratio enum, duration enum)
• Replicate, kwaivgi/kling-v3-omni-video input schema (start_image, end_image, reference_images, aspect_ratio, mode)
• Replicate, kwaivgi/kling-v2.6 input schema (start_image, aspect_ratio)
• Replicate, alibaba/happyhorse-1.1 input schema (images array, aspect_ratio)
• Replicate, bytedance/seedance-2.0 input schema (image, reference_images, aspect_ratio; field behaviour only, production runs on BytePlus)
• BytePlus ModelArk, Create a video generation task (image requirements, image counts, mutually exclusive scenarios; page last updated 4 September 2026)
• Replicate, bytedance/seedance-1.5-pro input schema (image, last_frame_image, aspect_ratio)
• Replicate, xai/grok-imagine-video input schema (image formats, aspect_ratio default)
• Replicate, bytedance/omni-human-1.5 input schema (image, audio limit)
• Replicate, veed/fabric-1.0 input schema (image, audio, resolution)
• Replicate, prunaai/p-video-avatar input schema (image formats, voice_script)
• Google AI for Developers, Generate videos with Veo 3.1 in Gemini API (reference images, aspect ratios, durations on Google's direct API)

All twelve were read on 4 September 2026. Schemas change when a vendor ships a new version; the field names above are how you check whether a row has moved.

Once the photo is right, the next questions are model choice and cost. Kling 3.0 vs Veo 3.1 compares the two most common picks, and the per-model cost benchmarks price every row in the table above. UGC Vids AI runs all of them from one upload, from $49/month, free for 3 days.