MiniMax H3 reference images: build a repeatable shot brief

AI-generated editorial illustration for this workflow, not a model test result.

MiniMax H3 reference images work best as a clearly labeled input set: identify which file supplies the subject, which supplies the setting, and what the written prompt asks to change. Keep that set stable across related shots, and check the actual output for continuity rather than assuming a reference guarantees it.

MiniMax H3 on Virse provides a model entry to inspect when choosing a workspace. This tutorial builds a local planning manifest and a file check; it does not document a Virse API, submit a generation request or report a model benchmark. Disclosure: This article was drafted with AI for Virse's content program.

In this guide: what should minimax h3 reference images control; how do you record the input set; can you catch missing inputs before generation; how do you write the action without changing the subject; what should remain stable across a sequence.

What should MiniMax H3 reference images control?

They should communicate the visual information that is difficult to express precisely in prose, while the prompt explains how that information applies to the shot. Keep identity, setting and visual treatment distinct in the planning document.

MiniMax's full-reference guide distinguishes reference subjects, concrete frame anchors and other media roles. Its detailed formatting belongs to that documented workflow. The simpler manifest below is an editorial planning format you can inspect locally, not a replacement for the provider's request schema.

Consider a fictional product film about an unbranded ceramic mug. A clean product image defines the mug's silhouette. A separate kitchen photograph suggests a setting. Another image might suggest lighting, but its furniture and props should not silently become part of the brief.

Use files you have permission to process and publish. Name them according to their job rather than their download order. subject.png is easier to review than an unexplained screenshot filename, particularly when another person needs to reproduce the input selection.

Build an input manifest. Original explanatory diagram; example instructions, not measured results.

How do you record the input set?

Create a small text file that records the asset paths, their roles and the intended shot. The example uses JSON because it is easy to read and validate with standard Python.

{
  "shot_id": "mug-reveal-a",
  "assets": [
    {"role": "subject", "path": "references/subject.png"},
    {"role": "setting", "path": "references/scene.png"}
  ],
  "prompt": "Keep the mug still. Move the camera slowly closer, then hold.",
  "review": ["silhouette", "handle shape", "surface contact"]
}

Save it as shot.json beside a references directory containing your own files. The path names are example filenames, not downloadable assets. The short prompt is deliberately narrow so that the first review has a clear question: can the shot preserve the object while the viewpoint changes'

Add the model label and visible generation settings to your project log when you run the actual job. Do not silently replace "MiniMax H3" with a similarly named variant. Different interfaces may expose different controls even when they use related model names.

The Python JSON documentation describes how json.loads converts this text into Python objects. No network connection or vendor credentials are needed to inspect the planning file.

Can you catch missing inputs before generation?

Yes. A local check can catch absent files, repeated roles and an empty prompt before you spend time setting up the shot in an application. It cannot verify whether an image depicts the correct product.

Save this as check_shot.py next to the manifest:

import json
from pathlib import Path

def check_shot(manifest):
    manifest = Path(manifest).resolve()
    data = json.loads(manifest.read_text(encoding="utf-8"))
    assets = data.get("assets", [])
    if not assets:
        raise ValueError("Add at least one reference asset")

    roles = []
    for asset in assets:
        role = asset.get("role", "").strip()
        if not role:
            raise ValueError("Every asset needs a role")
        if role in roles:
            raise ValueError(f"Repeated role: {role}")
        roles.append(role)
        filename = asset.get("path", "")
        if not filename:
            raise ValueError(f"Missing path for {role}")
        source = (manifest.parent / filename).resolve()
        if not source.is_file():
            raise FileNotFoundError(f"Missing {role} file: {source}")

    if "subject" not in roles:
        raise ValueError("This workflow requires a subject reference")
    if not data.get("prompt", "").strip():
        raise ValueError("Write a prompt before generating")
    return data

if __name__ == "__main__":
    shot = check_shot("shot.json")
    print(f"Input files found for {shot['shot_id']}")

Run python check_shot.py from that directory. An error identifies the input to fix. A successful result means that the files exist and that this small planning convention is satisfied. It says nothing about image quality, supported upload formats or whether the provider accepts those inputs.

The one-role-per-file rule is a convention for this example. If a project needs several subject views, extend the format with named roles such as subject_front and subject_side, then update the required-role check. Do not change the structure halfway through a series without recording the revision.

Python's pathlib documentation explains the path operations used here. The check resolves asset paths relative to the manifest so that the location of a reference does not depend on where an unrelated script happens to run.

How do you write the action without changing the subject?

Describe the action and the camera separately, then state the visual properties that matter at review. For the mug example, a subject that stays still and a camera that moves closer are different instructions.

Keep appearance separate from action. Original explanatory diagram; example instructions, not measured results.

Use an illustrative shot brief like this:

Use the mug reference for the cup's silhouette, handle and surface finish. Use the kitchen image only for the setting. The mug rests on the counter throughout the shot. The camera makes a slow, straight move toward the mug and finishes on a closer view of the handle. Keep the mug's position and orientation unchanged. Hold the final view briefly so it can be used as an edit point.

If a generated result rotates the mug while the camera also moves, you have a specific issue to diagnose. Simplify the camera instruction or make the object's stationary state clearer before adding further visual effects.

Avoid treating a long list of stylistic adjectives as a substitute for action. "Cinematic" does not tell a reviewer where the subject should be at the end of the clip. An observable endpoint gives both generation and review a clearer target.

What should remain stable across a sequence?

Keep the approved subject reference, the naming scheme and the product constraints stable. Change the shot description intentionally, and record each change next to the result.

For a small sequence, the mug could appear in an establishing shot, a handle detail and a final composition with space for copy. The framing changes, but its contour, finish and handle must remain recognizable as the same object.

Make a reference revision only when you intend to change what the model sees. If the initial image has a cropped handle, replacing it with a clearer view may be sensible. Record that replacement because it can affect the comparison with earlier clips.

For stricter file tracking, store a checksum in your project log. Python's hashlib module can calculate a file digest. A digest helps detect a changed file with the same name; it does not establish copyright ownership or prove that two images show the same product.

How do you review character or product consistency?

Review the beginning, the moments of significant movement and the ending, then watch the clip at normal speed. A still-frame check can reveal structural changes, while playback reveals temporal problems that isolated images miss.

Validate, then compare. Original explanatory diagram; example instructions, not measured results.

For the sample product shot, use this checklist:

• The handle retains its shape and attachment points.
• The rim does not change thickness during the camera movement.
• The base maintains believable contact with the counter.
• Reflections change plausibly with the viewpoint.
• The final composition provides the intended edit point.

For a character shot, replace the product checks with the relevant identity, wardrobe and pose details. Use an authorized reference and review the movement around occlusions, turns and interactions. Those are useful review moments because they demand a visible transition, not because this article establishes a measured model failure rate at those points.

Record a concrete reason for rejection. "Handle deforms during the approach" is more useful than "bad consistency." If a clip passes all mandatory requirements but you prefer another style, keep that distinction in the review log.

What can this workflow prove?

It can prove that your local inputs satisfy the checks you wrote and that your review record describes a specific output. It cannot prove that the model will preserve identity, that a provider supports every documented mode, or that the same prompt will return an identical clip later.

Before the first generation, inspect the chosen interface's current reference controls. If it accepts only still images, a video-reference workflow requires a different supported entry. Model documentation and application functionality should be checked separately.

Likewise, check the displayed price and available output settings in the actual application. This article deliberately makes no promise about H3 audio behavior, resolution or generation cost across providers.

Is a reference image the same as a first frame?

Not necessarily. A reference may guide the subject's appearance, while a first frame specifies the starting composition. Use the mode supported by your interface and state what the image is meant to control. Confusing those jobs can make a prompt ambiguous even when the uploaded file itself is correct.

Virse public page captured during editorial preparation. This screenshot documents the page, not a completed generation.

How should a team share the reference package?

Share a project folder containing the manifest, the approved references and the selected outputs. Keep those files together so that the relative paths continue to work when another person opens the folder on a different machine.

Add a short readme identifying the approved input version. Keep account credentials and private client material out of a public repository. When a collaborator returns a revision, ask for the changed prompt and any replaced references together. Compare that package with the earlier version before deciding what caused an output to change.

If the files are too large for your code repository, use the team's approved asset storage and keep a stable project record pointing to them. Run the local check after copying the files, then inspect the images. A valid path can still point to the wrong product.

What should you save after a successful shot?

Save the output, the manifest, the exact references, the prompt version and a short acceptance note. Include the visible model and settings used for the job. That package gives the next person enough context to make a deliberate revision instead of reconstructing the setup from memory.