Avoid instructions the model is bad at

A classic trap that lowers reproducibility is the negative instruction. Image models are poor at "do not draw X" and often draw it anyway. "A doctor smiling warmly at a patient" is more stable than "a doctor not holding a syringe." Write the desired state in the positive.

The other trap is contradiction. "A night scene but with bright daytime light" breeds broken outputs. Just keeping time of day, light source, and palette consistent visibly narrows the swing between hits and misses on regeneration.

The same prompt still varies — record to reproduce

This is where a gamble diverges from a repeatable workflow. The same prompt still produces varying results, which is exactly why recording prompt, seed, model, and timestamp together pays off when a good frame appears.

For each asset run I drop a one-line log: the brief, the model ID used, and the filename I shipped. That alone lets me reproduce, three months later, a request I make of myself like "same tone as that article's hero image." Generation without records is starting from zero every time.

Everything so far works in the app's UI or a browser-based ImageFX. From here we put the design onto the API and generate assets without human hands. A June 2026 update widened that doorway.

Generating a single image from a video — what the Nano Banana 2 (gemini-3.1-flash-image) GA changed

In June 2026, Nano Banana 2 (gemini-3.1-flash-image) and Nano Banana Pro (gemini-3-pro-image) reached GA. For indie asset generation the biggest piece is this: you can pass a video file as multimodal context and generate a thumbnail, poster, or infographic informed by its content (video-to-image is a gemini-3.1-flash-image-class use).

Previously there was a manual step of hunting for a good frame, cutting it out, and editing it. Passing the video directly lets you start from "turn the climax of this video into one vertical thumbnail." For indie developers handling stand.fm audio or short-form clips, it's a quietly meaningful shift.

The implementation is the same google-genai SDK flow as ordinary image output, with a video part added to the input. Small videos can go inline.

import os
from google import genai
from google.genai import types
 
client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])
 
# Nano Banana 2 = gemini-3.1-flash-image (GA, 2026-06).
# This family is what accepts a video as context.
IMAGE_MODEL = "gemini-3.1-flash-image"
 
def thumbnail_from_video(video_path: str, brief: str) -> bytes:
    with open(video_path, "rb") as f:
        video_bytes = f.read()
 
    response = client.models.generate_content(
        model=IMAGE_MODEL,
        contents=[
            types.Part.from_bytes(data=video_bytes, mime_type="video/mp4"),
            brief,
        ],
        config=types.GenerateContentConfig(
            response_modalities=["TEXT", "IMAGE"],
        ),
    )
 
    for part in response.candidates[0].content.parts:
        if part.inline_data is not None:
            return part.inline_data.data
    raise RuntimeError("No image part returned (text-only response)")

The brief is just the "shape" from the first half. For a vertical thumbnail: "Turn the climax of this video into one image. Subject large and centered, vertical 9:16, high-contrast for legibility, no text" — the four parts plus aspect ratio. I want to place the title text reliably downstream, so telling the image model not to add text keeps the pipeline stable.

Videos beyond a few tens of MB are safer through the Files API than inline. Swap the inline bytes for an uploaded file reference in contents; the call's skeleton is unchanged.

def thumbnail_from_large_video(video_path: str, brief: str) -> bytes:
    uploaded = client.files.upload(file=video_path)
    response = client.models.generate_content(
        model=IMAGE_MODEL,
        contents=[uploaded, brief],
        config=types.GenerateContentConfig(
            response_modalities=["TEXT", "IMAGE"],
        ),
    )
    for part in response.candidates[0].content.parts:
        if part.inline_data is not None:
            return part.inline_data.data
    raise RuntimeError("No image returned")

Even with IMAGE in response_modalities, responses come back in three mixes: text only, image only, or both. Looping over parts and treating something as an image only when inline_data is present is mandatory in automation. Skip that guard and a text-only response throws.

Passing the whole video is expensive — narrow it to the seconds that matter

The first wall I hit running video-to-image for real wasn't quality. It was the bill and the wait. Video input accrues tokens by duration, so handing over a three-minute file means paying for the entire clip in order to get the dozen seconds that actually shape the thumbnail.

While producing thumbnails for short videos, I missed this at first and lived with roughly forty seconds of wall-clock per image — a queue that stretched further with every added asset. Once I started trimming to the window around the peak moment before sending, the same quality came back in single-digit seconds, and token consumption dropped by an order of magnitude.

Trimming is one ffmpeg call. Audio is never used for image generation, so drop it — and lower the frame rate and resolution while you're there. A thumbnail needs composition and color, not smooth motion.

import os
import subprocess
import tempfile
 
def clip_window(video_path: str, start_sec: float, dur_sec: float = 12.0) -> str:
    """Cut the window around the peak so the video you send is small."""
    out = os.path.join(tempfile.mkdtemp(), "window.mp4")
    subprocess.run(
        [
            "ffmpeg", "-y",
            "-ss", str(start_sec),   # placed before -i for a fast seek
            "-t", str(dur_sec),
            "-i", video_path,
            "-an",                       # audio is unused for image generation
            "-vf", "fps=2,scale=-2:720", # lower frame rate and resolution too
            out,
        ],
        check=True,
        capture_output=True,
    )
    return out

That leaves the question of which second counts as the peak. I didn't want to watch every file, so I made it two passes. First I send the same video to a text-response model and ask it to answer with nothing but a number: at what second would you freeze this for a thumbnail? Then that second goes into clip_window(), and only the short window reaches image generation.

Adding a call to save a call looks like a bad trade until you weigh them. The text response is dramatically cheaper, and cutting the video that reaches image generation to a tenth outweighs it by a wide margin. Ask something cheap to aim, then fire the expensive thing once. That ordering has become my default shape for multimodal automation well beyond images.

A lightweight gate that rejects broken images before publishing

The scary part of automation is a broken frame flowing straight to publication. I did exactly this in wallpaper color-variant generation and shipped a flat, single-color image. Before adding heavy quality scoring, stopping obvious accidents with a cheap mechanical check is the realistic move.

The gate below decides, with no extra API call, whether the aspect ratio drifted from target and whether the image is nearly single-color (a generation failure).

from PIL import Image
from io import BytesIO
 
def passes_quality_gate(img_bytes: bytes, target_ratio: float = 16 / 9,
                        tol: float = 0.08) -> bool:
    img = Image.open(BytesIO(img_bytes)).convert("RGB")
    w, h = img.size
    ratio = w / h
    if abs(ratio - target_ratio) / target_ratio > tol:
        return False  # aspect ratio drifted too far from target
 
    # Detect near-single-color (flat / broken): inspect pixel variance after shrinking
    small = img.resize((32, 18))
    px = list(small.getdata())
    n = len(px)
    mean = [sum(c[i] for c in px) / n for i in range(3)]
    var = sum(sum((c[i] - mean[i]) ** 2 for i in range(3)) for c in px) / n
    return var > 150  # empirical threshold; below it, flat/broken images dominate

The 150 threshold is just my local empirical value. It needs tuning to your material, but even using it only as a "regenerate an obviously bad frame once" retry condition noticeably dropped my manual rework rate at volume. Rather than aiming for perfect quality judgment from day one, putting a cheap gate that stops only accidents first is the better cost-benefit trade for indie work.

Make your winners machine-readable — a generation ledger and series consistency

Earlier I said to record the good frame when it appears. But a note written for human eyes doesn't connect to automation. A record becomes an asset only once a program can look it up. I append one line of JSON per generation. No database, and keeping it in the repository means the history shows up in diffs.

import hashlib
import json
import time
from pathlib import Path
 
LEDGER = Path("generated/ledger.jsonl")
 
def record(brief: str, model: str, out_path: Path, adopted: bool) -> str:
    """Append one generation as one line. `key` identifies identical conditions."""
    key = hashlib.sha1(f"{model}\n{brief}".encode("utf-8")).hexdigest()[:12]
    LEDGER.parent.mkdir(parents=True, exist_ok=True)
    with LEDGER.open("a", encoding="utf-8") as f:
        f.write(json.dumps({
            "key": key,
            "model": model,
            "brief": brief,
            "file": str(out_path),
            "adopted": adopted,
            "at": time.strftime("%Y-%m-%dT%H:%M:%S"),
        }, ensure_ascii=False) + "\n")
    return key
 
def find_adopted(keyword: str) -> list[dict]:
    """Look up only adopted generations, by a word in the brief."""
    if not LEDGER.exists():
        return []
    rows = [json.loads(line) for line in LEDGER.read_text(encoding="utf-8").splitlines() if line]
    return [r for r in rows if r["adopted"] and keyword in r["brief"]]

The adopted boolean is what makes this useful. Being able to retrieve the frame you chose, rather than everything you produced, is the whole point. My own ledger sits near a twenty percent adoption rate; the other eighty percent stays recorded too, so I don't pay for the same miss twice.

Records earn their keep again when a series has to hold together. When I want the OGP images across four Lab sites to feel like one set, writing the palette and spacing in words still drifts from run to run. Handing back an already-adopted image as a reference turned out to be far more reliable than describing it.

def generate_in_series(reference_path: str, brief: str) -> bytes:
    """Anchor on an adopted frame to produce the next one in the same air."""
    with open(reference_path, "rb") as f:
        reference = f.read()
 
    response = client.models.generate_content(
        model=IMAGE_MODEL,
        contents=[
            types.Part.from_bytes(data=reference, mime_type="image/png"),
            "Keep this image's palette, texture, and use of negative space. "
            "Produce one new image with the following content.\n" + brief,
        ],
        config=types.GenerateContentConfig(
            response_modalities=["TEXT", "IMAGE"],
        ),
    )
    for part in response.candidates[0].content.parts:
        if part.inline_data is not None:
            return part.inline_data.data
    raise RuntimeError("No image returned")

Pull the reference with find_adopted(), pass it to generate_in_series(). Once those two mesh, a vague request like "the way that other one felt" becomes an executable step.

There is a side effect worth watching: anchor too hard and everything starts to look like the same picture. I keep the reference's influence to palette and texture, and vary subject and angle in the brief every time. Consistency isn't about making things match — it's about making them read as one body of work when placed side by side. That framing makes it much easier to decide how much to pin down.

Don't get caught by preview shutdowns — keep model IDs in one place

One more thing that always pays off in automation: deprecation handling. Preview models shut down on notice. In fact gemini-3.1-flash-image-preview and gemini-3-pro-image-preview are scheduled to stop on 6/25, and any code that hard-coded them will fail en masse with INVALID_ARGUMENT the moment they go.

The defense is simple: don't scatter model IDs through the code — confine them to one dictionary. When something shuts down, you follow with a one-line change instead of grepping the whole codebase.

# Keep model IDs in one place so a preview shutdown is a one-line follow-up.
IMAGE_MODELS = {
    "fast": "gemini-3.1-flash-image",   # Nano Banana 2 (GA)
    "quality": "gemini-3-pro-image",    # Nano Banana Pro (GA)
}
 
def resolve_image_model(tier: str = "fast") -> str:
    try:
        return IMAGE_MODELS[tier]
    except KeyError as e:
        # Don't silently fall back an unknown tier to a default; fail loudly
        raise ValueError(f"Unknown image model tier: {tier}") from e

I reuse the same generation base across several Lab sites and the wallpaper apps, so I register preview shutdown dates on an operations calendar and finish moving to GA versions the week before. Making time-bound deprecations something you "can't miss" is the best insurance when one person runs several projects.

Your next step

Start by taking one prompt that produced a winner and decomposing it into the four parts — subject, scene, style, detail — as a template. Feed that template as the brief to thumbnail_from_video() and you can run the minimal loop for generating assets from a video today. For the move after that, add one call to record() and start the ledger — it costs a line now and pays out three months from now. With records and shapes in hand, image generation turns from a gamble into a process you can reproduce. Thank you for reading.