I spent a week treating an AI video model like a system under test, and the most useful result came from a bug I nearly missed.
Setup: I designed an anime character with a fixed spec. Navy hair with a lighter gradient, warm hazel eyes, cream hoodie, olive jacket, silver headphones, a beauty mark under one eye. Call it a fixture. Then I fed her to PixAI v4.0 Preview as a reference image and asked for a five second clip.
The output looked correct. Motion held, style held, the character was recognizably her. I almost moved on. Then I checked the spec field by field, and her eyes were blue.
Isolating the variable
The interesting question is why, and the only way to answer it is the same way you would debug anything else. Change one thing. Rerun. Compare.
| Run | Reference shows eyes | Prompt states eye color | Result |
|---|---|---|---|
| 1 | no (back view) | no | blue, wrong |
| 2 | no (back view) | yes | hazel, correct |
| 3 | yes (front portrait) | no | hazel, correct |
Three runs, one variable each. The pattern falls out immediately: what the reference image fails to show, the model fills in with a plausible default. My back-view reference never showed her eyes. The model had a null and it filled it with something consistent with the rest of the input, and blue hair gets blue eyes.
The headphones did the same thing, coming back with black earpads where the reference only ever showed the outside of the cups.
If you have ever debugged a system that silently coerces a missing field into a sensible-looking default instead of throwing, this will feel familiar. The failure mode is identical, and so is the reason it is dangerous: the output is plausible enough to pass a glance.
Two independent fixes both worked, which is worth stating separately, because it tells you the model is reading both channels:
- Fix A: make the reference show the field.
- Fix B: state the field in the prompt.
Either one closes the gap. Neither is documented as a rule anywhere I could find, because it falls out of the interaction between the two inputs rather than from either one alone.
The reference is an input with two possible contracts
This is the part I would push on if you are evaluating any image-to-video tool. "Supports reference images" is meaningless until you know what the tool does with the reference.
PixAI v4.0 Preview happens to expose both behaviors as explicit modes, which made the comparison clean. Same reference image in both runs, a front-facing studio portrait on a flat gray backdrop:
First and Last Frames. The reference is the literal frame at t=0. The clip starts as the portrait, gray backdrop and all, and animates forward. Deterministic, and it welds your character to the pose and background you happened to draw.
Multi-Reference. The reference is a semantic identity anchor. The clip opened on a rooftop at dusk, a scene that exists nowhere in the reference image, with the character intact and the gray backdrop gone. The model pulled the subject from the image and the world from the prompt.
Same input, two contracts, two different tools. A generator that only implements the first is a constrained animator. A generator that implements the second lets one character sheet serve as the source for arbitrary scenes, which is the difference between a demo and a pipeline. The v4.0 Preview overview documents how the reference system is structured.
One counterintuitive detail: more reference images gives you less. The platform's own testing found two or three focused images outperform a larger stack, since averaging across inputs softens the result. My single clean portrait beat the atmospheric wide shot for one reason. It showed the face.
Camera direction is a real interface
I wanted to know whether camera instructions are decoration or API, so I wrote a five second clip as four ordered beats: open on a close-up of her hands on a railing, tilt up along her arm to her face, orbit slowly left, then pull back to a medium wide.
All four executed, in order, without a cut.
That means push in, pull back, tilt, and orbit behave as directives rather than vibes, which is directly testable on any candidate tool and takes one generation to check. Ask for an orbit left. If you get a drift right, you have learned something the feature matrix would never have told you. The prompt guide covers the syntax, including how the timestamp format itself signals a continuous take rather than a cut.
Iteration cost is an engineering constraint
Every result above came out of a rerun of something that failed first. That arithmetic belongs in the tool decision, and it rarely shows up in comparisons.
Concrete numbers from my runs, read off the panel before each generation:
- Five seconds on v4.0 Lite Preview: 27,500 credits
- Five seconds on v4.0 Preview: 70,000 credits
Roughly 2.5x for the same duration. The two share an architecture and take identical reference and audio inputs, so the recommended practice is to draft on Lite and commit to Preview once the direction is locked. That held up for me. The entire eye color investigation, all three runs, ran on Lite. Paying premium rates to discover that a prompt needed one more sentence would have been pure waste.
The evaluation question this raises: what does a draft cost against a final, and can you change one variable and rerun without rebuilding the whole setup? A tool that produces beautiful output at a price that discourages iteration is a tool you will use once.
The short version
If you are choosing an image-to-video tool for character work, the test that matters takes one afternoon:
- Build a fixture with a spec you can verify field by field.
- Give the tool a reference that deliberately hides one field.
- Check whether the output invents that field or leaves it alone.
- Rerun with the field stated in the prompt.
- Rerun with a reference that shows the field.
- Compare all three.
You will learn more from those six steps than from every comparison table on the topic, because you will find out exactly where the tool's defaults live. Mine put them at blue.
If you want to run it yourself, PixAI is where I did.
Top comments (0)