An image editor that takes natural language looks like a function call with named arguments. You describe a target, an operation, and a set of things that should stay put, and something comes back. The interesting failures are the ones where every argument you passed is present in the output, and the result is still wrong.
Here is the smallest example I have. The instruction was to move an object from A to B. The output contained the object at B. It also still contained the object at A. Every requirement satisfied, one implicit requirement missed: a move is a copy plus a delete, and the delete is the half nobody writes down.
I spent a session testing which implicit requirements PixAI's Tsubaki.3 model infers on its own. Eight edits, four categories, one fixture.
Test fixture
A single generated scene, built so every element is countable and nameable afterwards:
subject: greenhouse gardener
worn: one yellow rubber glove, left hand only
held_by: crow -> the matching right glove, in its beak
markers: 4 wooden plant labels, red shears in one pocket,
straw hat on a cord down her back
bench: tipped terracotta pot (centre), watering can (right edge)
control: second terracotta pot, same clay, never named in any instruction
That last line is the important one. Two objects of the same material, only one of them ever mentioned, gives you a free assertion on every material edit.
Fixed parameters across all runs: Pro mode, no style preset, default negative prompt untouched, prompt rewriting disabled, one edit per run from the same source. Free seeds, so single runs are observations rather than proofs.
Category 1: reference reassignment
Move the yellow rubber glove from the crow's beak onto her bare right hand,
so that she is now wearing a glove on both hands.
The crow's beak is empty and open.
Passed on all three assertions: object present at destination, absent at origin, and bound by the right relation (worn, rather than held). The duplicate-instance failure never appeared in this run.
The second spatial test asked for containment with specified occlusion: the crow inside the tipped pot, only its head visible, legs and body and twine hidden.
The bird went in tail-first, which inverts the occlusion spec exactly. Two unrequested mutations came with it: the pot rotated to face the opposite direction, and the twine unbound from the crow's leg and rebound around the pot. Both are consistent with making a tail-first insertion physically renderable at that camera angle. Read charitably, the model mutated whatever was not explicitly frozen until the requested relation became satisfiable.
Category 2: change the type, keep the instance
Change the terracotta pot she is holding to clear transparent glass,
so that the soil and tangled roots inside become visible.
The pot keeps exactly the same shape, size, and position in her hand.
| Assertion | Result |
|---|---|
| Material changed to glass | pass |
| Interior contents invented plausibly | pass |
| Silhouette preserved | fail, returned a straight-sided jar |
| No parts added | fail, gained a metal screw lid |
| Control object unchanged | pass, second pot still terracotta |
The control assertion is the useful one. Material change scoped to the named instance rather than to the type, which is the behaviour you want in a cluttered frame.
The silhouette failure repeated on the second material edit in a different direction. Asked to turn a straw hat on the character's back into hammered copper while keeping its shape and cord, the model delivered the copper and the brim, then relocated the hat onto her head and swapped the thin cord for a thick knotted rope. A single argument about material mutated a spatial relation that was never in the call.
Category 3: one instruction, derived consequences
Show this same greenhouse one second after the whole potting bench
tipped over onto the floor.
No consequences listed on purpose. The dependency chain resolved without being told: the bench is overturned and everything that had been resting on it is on the floor with the soil spilled.
Garbage collection was less tidy. The crow is gone from the scene with no trace. A second pair of shears appeared on the floor while the original instance stayed in the character's pocket. The watering can landed upright and undamaged. And with nothing airborne, the render reads as an aftermath state rather than the requested t+1s frame.
Category 4: text and layout
Three string operations plus one physical dependency, since the crow was perched on the title being replaced.
| Assertion | Result |
|---|---|
| Title replaced, exact string | pass |
| Date line added below, exact string | pass |
| Badge added with exact string | pass |
| Size hierarchy preserved | pass |
| Crow re-perched on the new title | pass |
| Badge placed in the named corner | fail, landed below the title on the right |
| Surrounding layout preserved | pass |
Worth noting from the generation side: producing the source poster took three attempts. The first two used a compound word in the display title, and across eight images none came back usable, with the same stray consonant inserted between the two halves every time all the letters were legible. The smaller caption line rendered correctly on every attempt. Text accuracy in generation and text accuracy in editing behaved like separate subsystems.
Does adding constraints help?
Two of the failures got a second pass with the missing constraint written out.
Pinning the hat's position worked completely. One clause stating that the hat stays on her back was enough to keep it there, keep the cord thin, and leave both control pots alone.
Pinning the pot's shape produced a mixed result. Naming the lid removed the lid. Naming the root direction fixed the root direction. Naming the category ("do not turn it into a jar") and describing the overall form did nothing, and the vessel came back as a jar with a threaded neck. The blast radius also widened rather than narrowing: on that run the control pot turned to glass as well.
The pattern across those two, at one run per variant: constraints naming a relation or a specific removable part held, constraints naming a class or a whole shape did not, and a longer defensive instruction bought no extra protection for anything else in the frame.
What I would take into a workflow
Relations between separate objects are safe to attempt in one pass, including the delete half of a move. Strings inside an existing design are safe. Type changes on an object need verification every time, and if two objects of the same material sit in one frame, check both.
The one-line version: name the relation you care about, including the one you want left alone, and put your assertions on the objects rather than on the scene.
If you want to run your own version, the cheapest possible test is two similar objects in one image and an instruction that names exactly one of them. Try your own advanced editing scenario with Tsubaki.3 on PixAI: https://eap.pixai.art/go/balazs
Top comments (0)