Source-image requirements for image-to-video models

The short answer: satisfy the published MCP input checks

For OfflineCreator Studio's published MCP 0.1.2 path, prepare a non-empty PNG, JPEG, WebP, or GIF file no larger than 10 MiB. For `filePath`, the published reader separately requires an allowed filename extension and bytes with a recognized PNG, JPEG, WebP, or GIF signature; it does not compare the extension with the detected type. For `imageBase64`, an optional `contentType` must match the type detected from the decoded bytes.

Start with an approved, rights-cleared frame that already matches the intended 16:9, 9:16, or 1:1 output shape. The ratio advice is a workflow choice, not a documented minimum-pixel rule. The current fal input schema does not publish a minimum width, minimum height, or maximum source-image file size, so this page does not invent provider thresholds. A live submission is still needed to verify the complete server-to-provider path.

Check bytes, type, size, and path before reserving credits

A practical preflight has four mechanical checks. First, confirm the file is not empty. Second, keep decoded bytes at or below 10 MiB. Third, for `filePath`, use an allowed `.png`, `.jpg`, `.jpeg`, `.webp`, or `.gif` extension and ensure the bytes contain any recognized supported image signature. Fourth, confirm the resolved path stays under the configured upload root and points to a regular file.

The published package performs these checks before it sends bytes to Studio. That establishes the MCP client's accepted input surface, not the full production acceptance contract. No accessible first-party page retrieved in this pass documents the current server-side media allowlist, and no authenticated upload was performed. If a project needs stronger proof than client-side validation, record an authorized upload response for the exact format before reserving a production batch.

Size

10 MiB maximum decoded image bytesBase64 text is larger than the decoded file; the package checks both an encoded-length guard and decoded byte length.

Type

PNG, JPEG, WebP, or GIF at the MCP client boundaryServer-side acceptance remains an explicit live-test gap in this research draft.

Type checks

Local paths and base64 inputs follow different checksThe local reader checks an extension allowlist and recognized bytes separately. The base64 reader compares contentType with detected bytes only when contentType is supplied.

Treat composition as a creative preflight, not an undocumented API rule

After the file passes mechanical validation, inspect the visible frame. Keep the subject fully inside the canvas, remove accidental edge crops, and choose a frame whose composition already fits the requested output ratio. If a logo, caption, hand, or product edge is essential, leave breathing room around it. These are conservative production heuristics for making motion review easier; they are not provider guarantees.

Use a clean source whose intended movement can be described without asking the model to rebuild the whole scene. Record the source filename, checksum, intended ratio, and a thumbnail in the project proof set. Confirm permission to send the image to a cloud generation provider and remove confidential or personal material that is not needed for the shot. No source reviewed in this pass supports a promise that text, faces, geometry, branding, or fine detail will remain unchanged.

Diagnose failures by the contract boundary they cross

A local-path error occurs before upload when a path escapes the upload root, has an extension outside the package allowlist, is empty, is not a regular file, exceeds the byte limit, or fails signature recognition. A base64 error occurs when the value decodes empty, exceeds the limit, is not a recognized image, or conflicts with an explicitly supplied content type. Correct the named client-side condition before retrying.

Provider acceptance remains a separate boundary. fal's current Kling 2.6 Pro image-to-video schema requires `start_image_url`, while the public MCP interface hides provider fields behind `generate` and `upload_input`. The accessible package artifacts establish the client-to-Studio request, but not the exact payload Studio sends onward. This research did not run a paid generation or capture a successful provider request, so it makes no claim about field normalization or current end-to-end acceptance.

Evidence boundary and monthly refresh checklist

This page documents source-image preparation that can be established from current public MCP artifacts and the current fal schema. It does not claim an ideal resolution, a guaranteed composition outcome, automatic rights clearance, a production server-side format allowlist, an exact provider payload, or successful preservation of any visual feature.

The recent research pass did not produce community evidence strong enough to support practitioner claims, and degraded or failed source lanes are treated as unknown rather than quiet. No community item is used as page evidence. Before editorial review, perform one authorized image-to-video acceptance run, record the upload response and outgoing provider contract without exposing secrets or private media, and refresh the package and fal schema.