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.

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.

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. With records and shapes in hand, image generation turns from a gamble into a process you can reproduce. Thank you for reading.