DEV Community: Merl Merl

One Reference Image, Eight Character Sheet Runs, and What the Model Made Up

Merl Merl — Tue, 01 Sep 2026 17:48:55 +0000

Character sheets are a reference format. Front, side, and back views, a range of expressions, a set of poses, enough detail that another person could work from the sheet without asking you questions.

The interesting engineering question is what happens when the input is underspecified. One image of a character does not contain the back of the coat. It does not contain the object hanging off a strap that runs behind the hip. Ask a model to expand that image into a full sheet, and it has to produce values for fields that were never set.

So I ran it as a controlled test on Tsubaki.3, the model PixAI currently has in early access, and measured what came back.

Test setup

One original character, generated once from text, then used as the only reference for every run after it. Eight generations: a turnaround, the same turnaround again on a different seed, a third with one sentence added, a six-panel expression sheet, a nine-panel expression sheet, a four-pose sheet, a single pose, and an outfit sheet.

Every setting held constant across runs: style preset off, Pro mode, Prompt Helper off, default negative prompt untouched, square format, one reference image attached.

The character design is the instrument, and it splits into three groups.

NAMED IN EVERY PROMPT      hair length and color, eye color,
                           red scarf, olive coat over grey sweater

REFERENCE ONLY             which side the hair tucks behind the ear,
                           which side the scarf tail hangs on,
                           strap across the chest with a metal slider,
                           notebook in the left chest pocket

ABSENT FROM THE REFERENCE  the back of the coat
                           the object on the end of the strap

The first group is the control. If those drift, nothing else is worth reading. They did not drift in any of the eight runs.

Result 1: silence is deterministic, promises are not

The turnaround came back with three genuine views at a matched scale: 983, 978, and 978 pixels tall in a 1024 pixel frame. The back view had to be invented, since the reference never showed it. It came out as a plain quilted panel with a center seam.

Then I ran the identical prompt, byte for byte, on a different seed. Same invented back. Same center seam.

That is the useful finding. An unset field gets a default, and the default is stable enough to rely on.

The strap behaves differently. The reference shows it crossing the chest and running to something behind the hip. Both turnaround runs dropped it entirely from the back view rather than resolving it, on two different seeds.

For the third run, I held the first run's seed and appended one sentence naming the bag. The bag appeared, correct material, correct hip. Two things came with it: a second strap crossing the first on the back, which no single shoulder bag produces, and the disappearance of the strap from the front and side views of that same sheet.

One added constraint, satisfied at the point of the constraint, paid for elsewhere in the same output.

Result 2: panel count is a real budget

Six expressions in a two-by-three grid was the strongest output in the set. All six visually distinct, the face measuring between 243 and 260 pixels wide across the panels, and a metal slider a few pixels across surviving at roughly 341 by 512 pixels per portrait.

Nine expressions in a three by three grid did something I did not predict. The faces stayed on model. The framing simplified: every panel squared up to the camera, the hair fell symmetrically, and a reference-only detail that held through all six panels of the smaller sheet vanished from all nine of the larger one. Two emotion pairs also converged, so nine slots produced seven clearly separate faces.

Result 3: the sheet format itself costs resolution

The pose sheet held proportions and broke layout. Four requested poses produced three distinct ones, and the crouching figure landed in the gap between two others at a different camera height instead of on the row.

More useful was running the same crouch as a single figure in the full frame. The notebook in the chest pocket renders at 71 pixels wide there against 32 on the sheet, with the cover, page block and spine thickness all readable. The reaching hand resolved into five separated fingers.

A quarter of a 1024 pixel frame has no room for that. The sheet was not failing at drawing; it was failing at budget.

What survived, ranked

Across every figure, the reference-only details came out in a clear order.

notebook in the chest pocket   25 of 26 figures wearing the coat
strap across the chest         23 of 26 front and side views
scarf tail on one side         10 of 17 full body figures
hair tucked behind one ear     14 of 26 views that face the viewer

The ordering is not random. The notebook is a high-contrast object in a fixed place on the garment, and every format keeps that place in frame. The strap depends on which side of the body is visible. The hair parting has no object holding it, so it goes first.

One caveat that cuts across all of it. The notebook and the strap are missing from the outfit sheet completely, because the coat they live on was replaced. Identity carried by an object lasts exactly as long as the object does.

Takeaways if you try this

Design for the format. Put the identifying details on objects, keep those objects on a garment you plan to keep, and treat anything that lives purely in the silhouette as the first thing you will lose.

Run the turnaround twice before you trust the back. The second run tells you whether the invented answer is a stable default or a coin flip.

If a detail matters, generate it as a single image rather than a panel. The overview and the detail are different jobs.

One last thing. Treat the output as a working reference rather than a production model sheet. Everything on it that your original image never showed is a plausible guess, which is a different thing from correct.

If you have one good picture of your OC sitting in a folder, the whole experiment costs you a few generations. Try it on PixAI and see which of your character's details are carried by an object and which are carried by luck.

Adding an Instruction Moved the Bug Instead of Fixing It

Merl Merl — Mon, 31 Aug 2026 19:35:52 +0000

Image models fail in a way that is hard to debug: the output looks fine. There is no stack trace, no assertion error, just a picture that is plausible and quietly different from what you asked for.

So I built a test fixture and ran nine controlled generations against it.

The fixture

One scene, described in exactly the same words in every prompt, with four objects placed so that I could check each one afterwards:

- red toolbox      -> viewer's left of the character
- metal ladder     -> viewer's right of the character
- ticket booth     -> further back, behind the wheel
- the character    -> standing at the foot of the Ferris wheel

The model under test was Tsubaki.3 on PixAI. Two rules kept the runs comparable. Only the camera sentence changed between prompts, and it came first, since these models read a prompt roughly in order of importance. Every test ran as a single generation instead of a batch, because selecting the best of four measures what the model can produce on the fourth attempt, which is a different question.

The baseline

The first prompt named no camera at all, and I ran it four times. All four came back the same way: eye level, character centered, full body, wheel behind him at roughly equal width on both sides.

The left and right assignments held in all four images. The booth, described as standing behind the wheel, ended up beside it every time. That split showed up in every later run too, so it is worth stating early: left and right are properties of the frame, behind is a property of the camera, and only one of those two moves when the lens does.

Test 1: camera height

Two prompts, identical except for one sentence. One asked for an extreme low angle with the camera almost on the concrete, the other for a bird's-eye view from the top of the wheel.

Both moved the lens instead of bending the pose. Boots large and close, horizon low, base legs splaying outward in the first. Hard hat crown dominant, legs foreshortened, structural shadows consistent with the viewpoint in the second.

The failure here is partial. In the low-angle run, the steel base directly behind the character reacted to the new viewpoint, while the wheel itself stayed a clean frontal circle with evenly spaced spokes, exactly as it looked at eye level. In the high-angle run, the same wheel turned correctly, its rim running out of both sides of the frame as two curves. Near geometry followed the camera, while distant geometry sometimes kept the view it already had.

Test 2: the regression

The depth prompt asked for three layers: toolbox very close to the lens, character in the middle distance beside the ladder, booth far behind him and much smaller than he is.

Result of run one:

Assertion	Outcome
toolbox in the immediate foreground, large	pass
character readable in the middle distance	pass
booth far back, much smaller than him	pass, around 40 percent of his height
character stands beside the ladder	fail, ladder moved to the booth

One failing assertion, so I patched the prompt. I added two phrases and changed nothing else: the booth got a frame position, near the right edge of the frame, and the character got one too, in the center of the frame.

Result of run two:

Assertion	Outcome
character stands beside the ladder	pass, fixed
booth near the right edge of the frame	pass
booth far back, half his height	fail, around 110 percent of his height
character in the center of the frame	partial, sits right of the center line

The patch fixed the failing assertion and broke a passing one. The booth moved to the right edge as instructed and came forward while doing it, its awning now above the character's hard hat. Two runs of the same scene, two different failure profiles, and the second was not obviously better than the first.

Test 3: the lens is a separate control

Fisheye has two parts. The lens has to bend the image, and the camera has to be somewhere specific for the bend to make sense. I asked for both: a fisheye shot from directly beneath the wheel looking straight up.

The distortion arrived, and it is convincing, with the concrete apron bowing into a wide arc. The camera position was ignored, and what came back has two viewpoints in one frame. The character is drawn from above, crown of the hard hat toward the lens, legs foreshortened, shadow pooled beneath him. The wheel behind him is drawn from below, base legs splaying downward, top edge tilting away.

The lens effect applied to the whole frame, while the camera position resolved separately for the figure and for the structure behind him.

Test 4: five constraints in one prompt

The last prompt stacked five requirements: low camera, toolbox in the immediate foreground on the viewer's left, character in the middle distance climbing the ladder with his back to the camera, an older man in a green coverall further back on the viewer's right holding a clipboard and looking up, wheel filling the background.

All five landed, including the back-turned pose, which I expected to be the weak point since turning a character away removes the face.

The busiest prompt in the test produced the cleanest result. The wording difference is that every element here carried a frame side alongside its distance, while the depth prompt named only layers. Whether the frame side is what carried the result, two runs cannot tell me.

What the nine runs support

Side of the frame: honored in every run where it appeared, including ground level, overhead, and fisheye.
Camera height: three clear results out of four, with the overhead run understating the distance.
Lens distortion: present in both runs that asked for it, independent of camera position.
Depth, near layer: landed in all three prompts that asked for one.
Depth, far layer: correct in two runs, slid forward in the third.
Size ratio between two objects: returned as written in neither of the two runs that asked for one. Much smaller than he is produced 40 percent; half his height produced 110 percent.

The camera is controllable on this model. The spatial relationships between objects are not deterministic across runs of the same prompt, and adding instructions to fix one relocated the variance rather than eliminating it. If you are building a pipeline on top of this, treat camera position as a parameter and object-to-object geometry as something you verify per output.

If you want to run the same experiment, the method is cheap: fix three or four nameable objects in your scene, write down where each one belongs, change one sentence per run, and check the output against your list instead of against your impression of it.

Try your own composition challenge on PixAI

Moving a Value Is Two Operations, and One of Them Is a Delete

Merl Merl — Wed, 26 Aug 2026 18:31:24 +0000

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

Measuring the Blast Radius of an AI Image Edit

Merl Merl — Mon, 24 Aug 2026 19:31:25 +0000

Instruction-based image editing has a failure mode that is easy to describe and hard to pin down: the requested change lands, and something you never mentioned comes back different. The face is a little off, an accessory is gone, the background warmed up by a few degrees.

The usual way to evaluate this is to look at the output and form an impression. I wanted numbers instead, so I set up something closer to a controlled experiment against PixAI's Tsubaki.3 and ran nine edits, the four main tests all starting from the same source image.

Setup

One source image, held constant. Same model, same mode, no style preset, no LoRA, prompt rewriting disabled, default negative prompt untouched, and a pinned seed. Once a base image is loaded the panel exposes no strength control, so there was nothing else to hold fixed.

The source was built as a test fixture rather than as a picture. Every identifying detail sits on one side only, which turns drift into something you can count:

left ear      silver hoop          right ear     nothing
right wrist   watch                left wrist    bare
right side    stethoscope head     left arm      two bandage squares
table         ginger tabby cat, white chest patch, one white front paw, red collar

The cat is the control. It sits in the middle of the frame, adjacent to everything I was about to modify, and exactly one of the nine instructions mentions it.

Measurement

For each result, I compared regions against the same regions of the source and took the mean per-pixel difference. Calibration matters more than the absolute values here:

Region type	Value when untouched
Flat wall	1 to 2
Detailed area, table edge	3 to 6
A region the edit changed	tens

Results

One instruction. Recolor a garment. Face 3.2, cat fur 5.0, cat eyes 3.8, watch 5.6, bandage 2.4, background 1.6. The change stayed inside the garment it named.

One structural instruction. Replace the outfit entirely, which forces the model to rebuild shape rather than repaint color. Stethoscope survived on top of the rebuilt torso. Both bandages survived. Cat at 4.5. Face at 10.1, against 3.2 in the recolor, with nothing in the prompt referring to the face.

Three instructions in one prompt. Cardigan color, held object swap, facial expression. All three landed. I then ran the same prompt twice more, once with a list of elements to preserve and once with that list plus the cat named by its markings. Whole-frame difference between the three variants: 1.4 to 2.6, which is background noise. The preservation list changed nothing measurable, because nothing in that run was under threat.

Four instructions plus an environment change. New location, new light source, new jacket, new held object, and a rendered sign reading ROOM 2. All four landed and the lettering came out clean. Color did not survive. The cat's fur went from an average RGB of (233, 181, 122) to (142, 149, 148), collapsing the channel spread from 111 to 7. Skin turned bluish grey and hair went near black, on a run whose preservation list named the face and hair explicitly, as most of the other runs did too.

The finding

Instruction count was the wrong variable. One instruction and four were carried with the same accuracy, and nothing was ignored across nine edits.

What scaled was reach. The disturbed area tracked how much of the picture the instruction obliged the model to reconstruct:

recolor a garment      -> stops at the garment edge
rebuild an outfit      -> reaches the face
change the light       -> reaches every surface whose color depends on light

The preservation list follows the same curve. At one instruction it had nothing to save. At three it made no measurable difference. At four plus an environment change it named the face and hair and lost both. It costs nothing to include and it stops being sufficient at the point where you start needing it.

Chaining is worse than batching

The obvious instinct is to split a complex edit into steps. I ran the three-change instruction as three sequential edits, each starting from the previous result, and measured how broken up the flat wall behind the subject became:

Route	Wall blockiness
Source	0.36
One prompt, three changes	0.40
Chained, step 1	0.43
Chained, step 2	1.21
Chained, step 3	7.35

By step three the breakup had spread onto the subject and the cat. Every pass re-encodes the whole image, and the artifacts compound in flat regions first. Instruction following survived the whole chain, and image quality did not.

I ran step two twice and got byte-identical files, so the result is reproducible on these settings. Whether a different seed avoids it is untested. Worth noting for anyone reaching for a retry: with the seed pinned, rerunning changes nothing at all. Freeing the seed or rewriting the instruction are the only two levers.

Practical takeaways

Batch related changes into one instruction. Four coordinated changes came through intact.
Expect a structural rebuild to move the face slightly. Check it against the original.
Expect a lighting or environment change to rewrite color on skin, hair and fur, and expect a preservation list to fail there.
Avoid chained passes on the same file. The quality cost is real and compounds.
Pin your settings before a comparison run. Half of this analysis only works because every edit ran on identical parameters.

The full write-up with all the before and after images is on Medium. If you want to run the same experiment on your own file, Tsubaki.3 is on PixAI. Take something you already like, change one small thing, and go audit the corners of the frame.

I ran 17 controlled generations to find out where AI manga panels break

Merl Merl — Fri, 21 Aug 2026 11:08:29 +0000

Garbled text inside generated images has been a standing complaint for as long as I have been using these tools. Recent releases claim to have fixed it, and I wanted to find out where the line actually sits.

So I set up a small experiment: one character, one model, seventeen generations, and a rule that every comparison changes exactly one variable. The subject is manga panels, because a panel is the one image format that has to carry artwork and text in the same frame and make both readable. The model is Tsubaki.3 on PixAI. I cannot draw, which for this purpose is a feature: everything below comes out of the prompt, with nothing rescued by hand afterward.

The setup

Treat the prompt as a function call with five arguments:

panel(
  scene,       # what is happening
  character,   # who, in full, every run
  framing,     # camera position and how tight
  dialogue,    # the line, and which corner it goes in
  treatment    # panel border, screentone, speed lines
)

The character argument stays identical across every run. That is what makes the rest of it measurable. Settings held constant too: no style preset, no LoRA, quality booster off, portrait 3:4, and the negative prompt left prefilled as it ships, with one deliberate exception below. Every comparison ran as a single generation rather than a batch of four, because picking the best of four is selection bias with extra steps.

Same character description, same action, two different treatment arguments. The left is a color illustration, centered, no border, no text. The right is the manga instruction: panel border, screentone, a lower camera, and the bubble. The room is identical. The treatment is the whole delta.

Finding 1: the negative prompt does not need touching

The default negative prompt on this model ships with text in it. That reads like a direct conflict with a speech bubble, so I ran the same panel twice, once as-is and once with text deleted.

There was no difference. Both runs produced the requested line, correctly spelled, in a clean hand-lettered balloon. Requested dialogue behaves like subject matter rather than like stray artifact text, so the negative prompt is not the thing standing between you and a bubble.

Then I raised the input length from two words to eight, with punctuation:

"PICK ANOTHER"                              -> correct
"THIS ONE IS BLURRY. THE CAPTION IS WRONG." -> correct, both periods

The bubble occupied about five percent of the frame in both cases. The model did not resize the balloon to fit more text; it shrank the glyphs and stacked them into three rows. Longer strings cost legibility, not area.

Finding 2: naming the bubble's position rewrites the composition

This is the result I did not expect, and it is the reason the whole experiment was worth running.

Three runs, one scene, one variable:

Run	Dialogue argument	Result
A	line only, no position	bubble self-placed on empty window area, cleared the face, no tail drawn
B	line plus "upper left corner"	bubble in that corner, and the character moved to the right side of the frame
C	B plus an explicit empty-third layout instruction	requested layout delivered, character shrank, tail came out as an open line

Run B is the interesting one. I changed four words in the dialogue argument and the model re-solved the whole composition around them: figure to the right, table rotated, upper left cleared. Nothing in the prompt said where she should stand.

The model treats the bubble as a layout element that has to fit, and it resolves the constraint by moving the artwork. That gives you a clean rule:

Name the corner. Do not also specify the layout.

Run C is what over-constraining looks like. Two instructions competing for the same rectangle, and the subject is what yields.

Finding 3: placement is reliable, the tail is not

Across the full set, balloon placement never failed. The tail failed in four different ways:

missing entirely
doubled, two tails aimed at the same speaker
drawn as a thin open line stopping in mid air, with the balloon outline broken where they should join
hanging into the gap between two characters, pointing at neither

If you are building anything on top of this, the tail is the element to flag for review. The balloon and the lettering held up without exception in my set.

Finding 4: prompt order predicts which character degrades

Two characters in one frame, described in sequence: the editor first and at length, the photographer second and more briefly. The line belongs to the photographer.

Visual separation held up: pale cropped hair against a black bob, a height difference, a camera on a strap. The bubble sat on his side of the frame and the tail angled toward him, so the association worked, if faintly.

The degradation was asymmetric and it repeated across two runs. Of the second character's five specified details, two failed the same way both times: glasses that were supposed to sit pushed up on his forehead came back over his eyes, and a bandage across his nose never rendered. The first-described character lost nothing.

I cannot see inside the model, so I will state it as a behavior rather than a cause: the subject written later and more briefly is the one that lost details, twice, in the same two places. Write the second subject at the same specificity as the first rather than summarizing it after.

Finding 5: a detailed description left the reference image little to do

Character drift is the standard complaint, so I measured it. Accessories and outfit survived well across the set. The face did not: it rounded out and aged up run to run, worst in an extreme close-up where the crop leaves the model the most to invent.

The expected fix is a reference image, so I generated a new scene twice, once from the description alone and once with my character sheet loaded as a reference. It changed the framing and gave her more hair. The face came out about the same either way. With a description carrying seven specified identity details, the reference had little left to correct.

Hairstyle was the outlier that nothing fixed. It ranged from close to the sheet in one panel to a tight pinned-up version in another, and the reference run produced the most extreme version of all.

What I would keep from this

Lettering held for every line I tried, up to eight words. Budget your cleanup time elsewhere.
Position the bubble by naming a corner, and let the model handle the rest of the arrangement.
Review the tail on every panel. It is the least reliable element on the page.
Write every subject in a multi-character prompt at full specificity, the second one included.
Describe held objects with the grip stated separately. Every run that asked for a photo held between two fingers returned a raised finger and a floating photo.
Compare with single generations. Batches let you pick winners and learn nothing.

A four-panel strip also held together in one generation, with the beats in written order and set dressing holding its position across panels, which is the part that makes a sequence read as one scene.

If you want to run your own version of this, the model is Tsubaki.3 and the useful discipline is changing one argument at a time: try it on PixAI and see which of these behaviors reproduce for you.

The Reference Carried the Count, the Prompt Carried the Layout

Merl Merl — Tue, 18 Aug 2026 19:52:36 +0000

There is a piece of advice that circulates around reference-based image generation: once you attach a reference image, keep your prompt short. Describe the new scene, leave the character alone, because re-describing what the reference already shows will fight it.

I wanted a number on that, so I designed a character to fail in measurable ways.

Designing a character as a test fixture

The character is an original design called Asagi, built on PixAI with the Tsubaki.3 model. The visible design has seven components, but two of them exist purely as assertions:

A count. Three small brass bells on a braided green cord at his sash. Countable at a glance, and wrong answers are unambiguous.
A side. A black leather arm guard on one forearm, a white cloth wrap on the opposite wrist. An asymmetric pair, so a failure shows up as either symmetry or a swap.

Everything else in the design - the indigo haori with a mustard band, the jade green eyes, the pale ochre lock of hair, the thin scar across one eyebrow - serves as background signal. The bells and the arm pair are the assertions that either pass or fail.

This matters because "does it look like the same character" is not a testable claim. "Are there three bells?" is.

The test matrix

Three conditions, same scene, same model, same settings:

condition A:  prompt only          (full character description, no reference)
condition B:  prompt + reference   (full character description, reference attached)
condition C:  reference only       (scene described, character not mentioned)

The scene was identical in all three: the character seated at a low table in a sunlit tea house. Condition C's prompt reads in full:

The same character sitting at a low table inside a sunlit tea house
in the daytime, a small cup in front of him, relaxed expression,
paper screens and warm wooden beams behind him, upper body and
both hands visible, anime illustration.

Results

Condition	Bell count	Asymmetric pair
A, prompt only	5 (and 2 on a repeat run)	correct
B, prompt + reference	3	correct
C, reference only	3	collapsed to matching cuffs on both arms

Condition A never got the count right across two runs. Two bells the first time, five the second. A number in a prompt behaves like a density hint rather than an integer.

Condition C got the count right and lost the layout. The reference carries what a pixel-level encoder can carry: the shape and color of a bell cluster, the geometry of a face. Which forearm wears what is a relational fact, and the model resolved it toward the symmetric default.

Condition B was the only pass on both assertions. The advice I started with is too broad: the reference and the description populate different fields, and supplying both costs one extra sentence.

Does stacking references help?

Tsubaki.3 accepts up to three reference images, so the obvious follow-up is whether more references buy anything. I ran the hardest prompt in the set, a full-body low-angle shot in a storm, with one, two, and three references attached. Then I repeated the whole ladder with a second fixed seed, so the reference count was the only variable.

seed 1:  1 ref -> 3 bells   2 refs -> 3 bells   3 refs -> 5 bells
seed 2:  1 ref -> 3 bells   2 refs -> 3 bells   3 refs -> 3 bells

Five out of six correct, and the single failure did not reproduce. Run-to-run variance is larger than any effect from the extra reference slots. One good reference did the job, and I would treat the second and third as optional rather than an upgrade path.

More inputs usually means more constraint. Here it did not, and the feature invites the opposite assumption.

What survives a wardrobe change

The destructive test: I moved the character out of a period haori into a bomber jacket and jeans on a modern crosswalk, which deletes every clothing-bound component of the design by definition.

Surviving: hair, the ochre lock, eye color, face.
Gone with the outfit: haori, bells, arm guard, as expected.
Gone unexpectedly: the eyebrow scar and the cord tying his hair at the nape.

The useful abstraction here is that identity splits into body-bound and clothing-bound components, and a wardrobe change is a scoped delete on the second group. If a character's recognizability is entirely stitched onto one jacket, the character has a single point of failure.

The scar went missing again in a six-panel expression sheet generated from the same reference. The pattern across both: the finest facial detail drops when the output format diverges sharply from the reference, and a grid of six small heads is a long way from one figure on a street.

Notes from the panel

Three implementation details that cost me runs before I understood them.

Attachment order matters. Attach the reference, then write the prompt. Adding it afterward reset my settings more than once.

The output inherits the reference's aspect ratio. My reference was 16:9, and every reference-based generation came back wide regardless of what I set. My first prompt-only run, with nothing attached, defaulted to portrait and had to be set by hand.

The prompt you send is not the prompt that runs. PixAI displays a rewritten version beside your input, and that version had pulled a physical description of the character out of the attached image. Reading it told me which traits the system extracted and which it invented. If you are debugging an unexpected result, this field is the first place to look.

The takeaway

Character consistency is not one property. It decomposes, and the components have different failure modes and different owners:

The reference owns counts, faces, palette, silhouette.
The prompt owns arrangement, sides, and everything relational.
Neither owns the finest details once the output format moves far enough away.

If you work with recurring characters, build one or two countable, one-sided details into the design on purpose. They cost nothing, and they turn consistency into something you can check rather than something you squint at.

Try it with Character Reference on PixAI if you have a character sitting in a folder that deserves more than one image.

An AI Image Edit Is a Full Re-Render, and Nine Runs Showed Me What That Costs

Merl Merl — Sat, 15 Aug 2026 09:12:53 +0000

Instruction-based image editing looks like a targeted operation. You hand a model an image, type "replace the cup with a bouquet", and get the image back with a bouquet in it. The mental model that suggests is a patch applied to a region.

That mental model is wrong, and the cost of it being wrong shows up in details you were not looking at.

I spent a week running edits against a single source image to map the behavior. The subject was an anime bike courier I generated for the purpose: mint green undercut, slate blue jacket with one orange chest stripe, a fingerless glove on one hand, three enamel pins, a red bandana on the other wrist, a coffee cup, and a chalkboard sign next to him reading OPEN. Deliberately full of small, countable details, because those are the things you can measure.

Nine runs. Eight instruction edits on the same model, one masked run for comparison.

The setup

The edits ran on PixAI with Tsubaki.3, its newest model. Worth noting for anyone reproducing this: the source image goes into a Base Image slot that accepts exactly one file, and once it is loaded, the aspect ratio control disappears from the panel. The edit inherits the frame of the input. All eight outputs came back at the source image's exact dimensions, which makes before and after comparison trivial.

One more setting matters. There is a prompt helper that rewrites or translates your input before it reaches the model. Leave it off if you want to attribute results to your own wording.

Discrete swaps land, structure does not

The clean successes were attribute and object level.

A hair color change from mint green to navy came back correct, with the haircut, the shaved side, the jacket, and the face intact. A hand-held object swap, coffee cup to a paper-wrapped bouquet, came back with the grip and the wrist position preserved, which is the interesting part, since hand and object are drawn together.

Structural requests failed. I asked three separate times for a limb to move: twice for the gloved hand to come off the handlebar and point at the sign, once for the arm holding the cup to lift toward his chin. Nothing moved in any of the three. My first hypothesis was frame cropping, since the first arm sat half outside the image. The third attempt used an arm fully inside the frame and produced the same non-result.

Background replacement landed halfway. Asking for a rainy night street produced rain streaks and warmly lit windows while the daylight on the character and the pavement stayed exactly as bright as before. The additive parts of the request arrived; the parts requiring a global relight did not.

So the boundary is between local and global, and it is sharper than I expected.

The preservation clause is a real control, with limits

Half of my runs carried a long clause listing what had to stay unchanged: face, hair, glove, strap, pins, bandana, sign text, background, lighting, framing, art style.

The two variants of the gesture instruction looked like this:

# variant A, bare
Lift his gloved hand off the handlebar so he is pointing at the chalkboard sign.

# variant B, same instruction plus the keep list
Lift his gloved hand off the handlebar so he is pointing at the chalkboard sign.
Keep everything else unchanged: his face, his mint green undercut and the shaved
side, the silver hoop in his ear, the slate blue windbreaker and its single orange
chest stripe, the fingerless glove on that same hand, his other hand bare, the
crossbody strap, the three enamel pins on his chest, the red bandana on his wrist,
the paper coffee cup he is holding, the bike, the text on the chalkboard sign, the
shopfront and awning behind him, the lighting, the framing, and the art style.

Neither run performed the requested change, so everything else in the diff is drift. Without the clause, the glove changed from black to brown and his mouth opened. With it, both held.

The clause narrows the drift. It does not close it. Two items proved immune in every run that carried them:

The three enamel pins. Count preserved in all eight runs. Colors and designs different in all eight.
The text on the chalkboard. Seven runs had a goal other than the sign. All seven damaged it. Six of those seven named the sign text explicitly in the keep list.

The failure modes on the sign are worth listing, because they are not subtle: OPEN became handwritten scribbles, then handwriting with a small drawn heart, then something close to Pittal, then ANLEKN, then COFFFE, then DIUDE, then Nami with an accent over it.

The same model renders text well when text is the target. Asking for the board to read CLOSED produced correct spelling, correct placement, and a convincing chalk texture. This yields the one operational rule I would put in a runbook: text is the last edit in the chain, because any later edit will roll it.

Where the mask wins, quantified

Inpainting means painting a mask over the region you want changed, so the tool knows the edit is confined to that area, then describing what belongs there. It costs you brush work, and it buys you a scope guarantee.

I ran the same cup-to-bouquet change through a mask and diffed both results against the original.

Method	Share of the frame that changed
Instruction edit	~17%
Masked inpaint	~2%, nearly all inside the mask

The masked run left the chalkboard reading OPEN and the pins in their original colors. It also produced a visibly different bouquet, tied with a ribbon rather than wrapped in paper, which follows from the Edit panel running its own model rather than Tsubaki.3.

What I would tell my past self

One change per run. Every run is a full re-render, so each additional request is another chance for something unrelated to move.
Write the keep list. It measurably narrows drift, and it will not eliminate it.
Local and discrete for instructions, global for regeneration. Pose and setting belong to a new generation, not an edit.
Text last.
Branch from the original for each new edit rather than chaining. Two runs redraw the small stuff twice.
Diff against the original, not against memory. The pins are the thing you will never notice by eye.

The broader point is that "edit" in these tools is a compatibility label for something that behaves like conditional regeneration. Treat the output as a new image that happens to look like the old one, and your review habits fall into place.

If you want to try the same tests on your own image, the model I used is here: PixAI

The Prompt Was Fine. The Input Had Already Consumed the Instruction.

Merl Merl — Thu, 13 Aug 2026 16:44:19 +0000

I spent an afternoon on what looked like a prompt engineering problem and turned out to be an input validation problem.

The setup: PixAI shipped Studio at the start of August, a node canvas where images, video, text and audio are all assets on the same graph, connected by edges. Image-to-video, so the picture is the input and a text instruction describes the motion. I had a finished illustration of an original character sitting in my gallery and wanted a five second clip out of it. Image in, motion instruction in, video out.

Three runs, one source image, three instructions. The results ordered themselves in a way I did not predict.

Run 1: the greedy instruction

I wrote the version I expected to fail, on purpose. Six requests in four sentences:

She turns all the way around to face the camera, pushes off the hull
with her right arm, and reaches toward the viewer while debris rushes
past her. The camera orbits around her and pushes in at the same time.
Bright flashes of light, sparks, fast dramatic movement.

Character rotation, a physical push, an arm extension, two simultaneous camera moves, environmental particles, lighting changes. Everything you would expect to blow up.

It executed all of it. The face held. The signature details held.

https://pixai.art/artwork/2042584634831661526

Run 2: the disciplined instruction

So I did what you do after an overloaded call succeeds by accident: I reduced the surface area. One primary action, named invariants, one camera move.

The character drifts slowly in place and turns her head toward the
camera, coming to rest facing the viewer. Her floating hair and the
orange cable sway gently with the motion. The camera pushes in slowly
and steadily. Her face, the lens over her right eye, the collar ring
and the armored glove on her right hand stay unchanged throughout.

Tighter, more explicit, better written by every measure I would apply to a prompt.

The output was a few degrees of head rotation. The supporting elements moved, the camera push landed, and the primary action, the thing the whole clip was built around, effectively no-opped.

https://pixai.art/artwork/2042584865220486332

The actual failure

The instruction was not the problem. The input was.

She was drawn facing the viewer, gaze locked on the lens. turn her head toward the camera describes a state transition from A to B where the source image was already at B. The instruction was well formed and semantically empty against that particular input.

This is the same class of bug as passing a correctly typed argument that happens to be a no-op for the current state. Nothing errors. Nothing warns. You get a successful run and an output that does nothing, and you go looking in the wrong layer.

Run 3: same input, different axis

The fix was not less instruction. It was moving the request onto an axis the input had left unconsumed: depth, camera travel, trailing elements, environmental motion, lighting. Everything except a rotation that had already been applied at draw time.

The character pushes off hard and accelerates forward through the
wreckage, her long hair and the orange cable whipping out behind her.
Broken metal fragments and dust streak past the lens in the foreground.
The camera pulls back and tracks with her. A hard white flare of
sunlight sweeps across the frame from the left as she passes. She keeps
looking straight ahead at the camera the whole time.

That one shipped.

https://pixai.art/artwork/2042585046943800636

What generalizes

Inspect the input before writing the instruction. For image-to-video specifically: what state is the subject already in, what is occluded, how much empty space exists in the direction of intended motion, and how well does the subject separate from the background. Any request that targets a state the input already satisfies produces a silent no-op.

Sort the frame into four buckets first. Primary movement, supporting movement, invariants, camera. The last one is the cheap lever. A camera move carries a shot while the subject stays nearly static, which is also the safest option when the artwork itself is the payload.

Name your invariants explicitly and pick asymmetric ones. My character has a lens over one eye and a glove on one hand only. Asymmetric markers are far easier to verify across frames than "the face looks right," the same way a distinctive sentinel value beats eyeballing a diff.

Declare the style contract twice. I ran a black and white manga panel through the same pipeline and stated black and white at the start and the end of the instruction. Ink, hatching and screentone, the dot shading that stands in for gray in printed manga, all survived, because the movement went to the camera rather than the drawing.

Failed runs are free, and version history makes comparison cheap. Every attempt stays as a node on the canvas, so three runs sit side by side without any bookkeeping on your side. Rewriting the instruction two or three times is the normal path, and treating run 1 as a probe rather than an attempt saves a lot of time.

The thing I keep coming back to: run 1 was the sloppy instruction and it worked, run 2 was the careful one and it did nothing. Prompt quality was not the variable. The input was.

Three runs, five seconds each, and the only variable that mattered was one I had not looked at.

The workspace is here if you want to try it.

I Built an Anime Art Pipeline on a Node Canvas and Watched Every Handoff

Merl Merl — Tue, 11 Aug 2026 19:20:25 +0000

If you have ever wired up a data pipeline, you already know the shape of this problem. Each stage transforms something and hands it to the next one. The interesting failures rarely happen inside a stage. They happen at the boundary, where one thing gets passed forward, and three other things quietly get dropped or silently inherited.

I ran the same experiment on a creative task. I cannot draw, so I make anime characters with AI tools, and until recently my process was the manual version: generate, download, open the next tool, upload, retype the character description because the next tool has no idea who she is. The file crosses the boundary. State does not.

So I rebuilt the whole thing on a node canvas, in PixAI Studio, and paid attention to exactly what crossed each edge.

The graph

The finished workspace looked like this:

character_sheet (imported)
    └── night_scene (text to image)
            ├── dawn_variant  (edit)
            └── clip          (image to video)

Four nodes, three edges. A node is one step holding one asset. An edge means the output of the upstream node is the input of the downstream node. Nothing exotic, which is the point: the mental model is function composition, and the value is that intermediate results stay addressable instead of ending up in a downloads folder as image (7).png.

The task

Deliberately small, because a scoped task makes the measurement clean. Target output: a five-second looping wallpaper, widescreen, of an original fox spirit character sitting on shrine steps at night.

That one sentence acted like a type signature. Widescreen ruled out a portrait frame. Looping ruled out one-directional motion, at least in theory. A seated pose ruled out anything busy. Writing it first is the equivalent of defining the contract before implementing against it.

The graph as it rendered on the canvas. Every later node draws its input from an earlier one.

What crossed each boundary

Import to generation. The character came from my own library rather than an upload, and it brought its full prompt, its model, and its frame shape along. Three of those four were useful.

Generation to selection. Four candidate images arrived inside the same node. Picking one is an explicit action, and it is the only step in the whole run where the tool cannot help you.

Selection to edit. The picked image appeared in the edit step's reference slot with no attachment step on my side.

Selection to video. Same thing. Dragging an edge out of the image node and choosing video created the downstream node with the source picture already bound.

Left column, what arrived by itself. Right column, what still needed a decision.

The three failures, which are the useful part

Silent inheritance. My character sheet was portrait. The scene node inherited that frame shape, and my widescreen wallpaper came out tall. Defaults propagating downstream is helpful right up to the moment a stage needs something different. Check the format at every node that produces something new.

An overly broad transform. I asked the edit step for one change, night to dawn. I got the light I asked for and a gate in the background that had not been there. Continuity across stages is real, and it has edges. Narrow instructions, verified one at a time, preserve more of what you already accepted.

A spec that failed to constrain. My clip does not loop cleanly, because falling leaves move in one direction and the last frame never meets the first. The bug is in the requirement, not in the video step. "Looping" was a word I wrote down without deciding what it excluded.

When the graph is worth building

The overhead pays off when one asset feeds several outputs, when you move from stills into motion, or when you want a process you can rerun next month without reconstructing it from memory. For a single standalone image, a plain generator is faster, and there is nothing to organize. Reach for the canvas at the point where your project has stages.

Video generation also costs meaningfully more than image generation, which is a decent argument for putting the review gate before the expensive node rather than after it.

The whole build took an afternoon and produced one five-second clip. What I came away with was a clearer map of which stages carry work forward and which ones quietly hand it back.

If you want to try the same experiment, start a workspace on PixAI and take one character all the way to a finished output. Watch the boundaries rather than the nodes.

The Version Matrix Problem in AI Character Art

Merl Merl — Wed, 05 Aug 2026 20:06:00 +0000

Anyone who has managed dependencies will recognize the shape of this problem, even without touching an image generator.

I spent an afternoon running the same original character through Midjourney and PixAI, and the interesting result had nothing to do with image quality. It was a compatibility matrix.

The test subject

One character, described once in plain language: an adult woman in her mid-thirties, cropped ash grey hair with a thin braid, a scar through the left eyebrow, steel blue eyes, a brass monocle on a chain, a heavy navy coat with a high collar, a leather wrap on her right forearm, and a small brass clockwork falcon on her left shoulder.

Eight checkable attributes. Same description on both platforms, no cherry-picking between them.

The matrix

Midjourney's version dropdown, as of early August 2026, runs from 1 through 8.2, with 8.2 as the default since July 24. Below a divider sit the anime models: niji 7, niji 6, niji 5, niji 4. The compatibility that matters for character work looks like this:

feature                     available on
--------------------------  --------------------------------
current default model       8.2
anime models (niji)         stops at niji 7
Omni Reference (character)  version 7
Character Reference (old)   version 6
editor, pan, zoom           documented as running on 6.1

Read that as a dependency graph, and the problem is visible before you generate anything. The newest model, the anime models, and the character lock resolve to three different versions.

What the runtime actually does

Three behaviors showed up in testing that the matrix alone does not tell you.

Loading a reference silently changes your model. Midjourney's documentation states that adding a reference image runs the prompt in version 7. My reference runs came back in that model's rendering style rather than the painterly output the default model had produced minutes earlier. Nothing in the flow asks whether that tradeoff is acceptable.

The anime models reject the parameter outright. Loading a reference on niji works, and then a line comes back saying niji does not support OW, the weight setting that controls reference strength. Style reference is offered instead, and a style reference transfers a look rather than an identity.

Reference state does not persist. The reference has to be attached again for every run. I changed the scene, generated, and got a different woman: brown wavy hair instead of ash grey, different face, different age. Zero warnings, zero errors, just a batch produced without the input I assumed was still bound.

Set up correctly, version 7 handled the character well across two scene changes. The hair, the build, and the coat carried over. The brass falcon arrived as an ordinary bird every time, and the clothing color drifted from run to run.

The other path

PixAI approaches this as one runtime rather than a matrix. You pick an anime model, Tsubaki.2 in my case, and the reference tools, the LoRA layer, and the editing tools sit in the same generation panel. A LoRA is a small add-on file trained over a base model that teaches it a style, a character, or a detail treatment, and the platform supports both community LoRAs and training your own.

The result I did not expect: running the same written description across three scenes with no reference image loaded produced the same person each time. Market at noon, workshop at night, rain on a pier. Different outfits, different expressions, and the identifying details held, brass fittings on the falcon included.

It is imperfect. The scar migrated to her cheek in one image and coat details vary. What it removes is state management: nothing to re-attach, no version to switch, no feature that exists on one branch and not another.

When each one is the right call

Midjourney remains excellent, and for single images or style exploration the version matrix never comes up, because you stay on one model and generate. Its aesthetic tooling is deeper than most, and it needs a paid subscription before the first image, starting at ten dollars a month.

The matrix starts costing you when a character has to survive twenty images across six months. At that point, the question stops being which model renders better and becomes how much setup stands between you and image number twenty.

If that is the work you are doing, see how far one description gets you in PixAI. The quick start guide covers the interface basics.

The Most Downloaded Model Was the Wrong Dependency

Merl Merl — Tue, 04 Aug 2026 14:44:09 +0000

Model libraries work like package registries. You search, you sort by popularity, you read the stars, you take the top result. That heuristic is good enough almost everywhere, so I used it, and it produced a worse result than doing nothing at all.

Here is the run.

The spec

The artifact under test is a character. It is written down, it does not exist as an image, and the description is the only source of truth. Seven assertions:

character: bram
role: lockmaker
age: 40s
build: short, broad, barrel chest      # the load bearing one
hair: bald, geometric tattoo on left scalp
beard: copper red, two braids, brass ring on each
eyewear: brass jeweler's loupe over right eye
torso: leather apron with tool loops
under: moss green tunic, teal embroidery
belt: ring of brass keys
arms: studded leather bracers, old burn scars

Two environments, same spec, same target output.

Environment A: resolve the dependency yourself

The generator opens with a model already selected. Search the model library for "anime" and you get zero results, because the search is scoped to whichever ecosystem is currently active and the default ecosystem has no such model. There is a dropdown that sets that scope. Until you find it, every query runs against the wrong index.

With the scope corrected, the top anime checkpoint reports over 450,000 downloads across its versions and a review score of Overwhelmingly Positive from almost 1,500 reviewers. By every signal a registry can give you, that is the correct resolution.

Switching to it changed the runtime config underneath. A negative prompt field appeared, and the sampler, step count, and CFG scale all moved to new defaults.

Decisions required before the second image:

#	Decision	Discoverable from the UI?
1	Find the ecosystem dropdown	Only after a failed search
2	Re-run the failed search	Yes
3	Choose the model family	Requires prior knowledge
4	Search the checkpoints	Yes
5	Choose a checkpoint	Yes, by popularity
6	Choose its version	Yes
7	Set CFG	Yes, with a labelled preset
8	Set the sampler	Yes, with a labelled preset
9	Set the steps	Yes, with a labelled preset
10	Write a negative prompt	Field appears, content is on you

Item 3 is the interesting one. It is the only step where the interface cannot help, and it is the step that determines everything downstream.

There is also a prompt-language change that costs zero clicks and matters more than any of the ten. Community anime checkpoints in this family are SDXL-derived and expect comma-separated tags. The spec had to be rewritten:

1boy, solo, male dwarf, adult man, 40 years old, stocky build,
broad shoulders, barrel chest, short stature, bald head,
dark geometric head tattoo on left side, long copper red beard,
braided beard, brass beard rings, brass jeweler's loupe over right eye,
brown leather apron, tool loops on apron, moss green tunic,
teal embroidered cuffs, ring of brass keys on belt, leather bracers

Negative prompt:

child, kid, young boy, teenager, youthful face, beardless,
tall, slender, thin body, feminine, 1girl, bad hands, bad anatomy

Results

Assertion	Environment A, default model	Environment A, top checkpoint	Environment B
build: short, broad	pass	fail	pass
bald + tattoo	pass	pass	pass
beard braids + rings	pass	pass	pass
loupe over eye	partial, held in hand	partial	pass
apron with tool loops	fail	fail	pass
moss green tunic	pass	fail, torso bare	pass
brass keys on belt	pass	pass	pass

Two runs at two aspect ratios on the top checkpoint. The build assertion failed both times, with three positive tags asserting it and two negative tags excluding the opposite.

The default model, resolved by nobody, satisfied it on the first run.

Why the heuristic broke

Popularity ranking optimizes for the median request. A checkpoint with 450,000 downloads is fine-tuned toward what most users generate, and a stocky forty-year-old tradesman sits outside that distribution. The registry sorted correctly. My input was out of sample, and nothing in the metadata exposes that, because the metadata describes adoption rather than coverage.

This is the same failure mode as picking a library by GitHub stars for a use case its maintainers never targeted. The signal is real. It is measuring somebody else's requirements.

Environment B: keep the default

PixAI loads an anime model when the generator opens. I kept it, wrote the spec as prose instead of tags, set the aspect ratio, generated. Three decisions, one of which was the picture size.

Worth noting for anyone moving between the two: this model is a DiT architecture rather than SDXL, so there is no negative prompt field and no bracket weight syntax like (tag:1.3). Exclusions go in the positive prompt as plain statements. If you carry an SDXL prompt across unchanged, the weights are ignored silently.

All seven assertions passed. From there, three scene variants ran on random seeds with only the scene clause swapped, and the character held across all of them without a reference image and without a locked seed.

  A bald dwarf man in his forties, short and broad, copper red beard
  in two braids each bound with a brass ring, dark geometric tattoo...
- Plain warm grey studio backdrop, even neutral lighting.
+ Walking across a stone bridge market at night, lit lanterns overhead.

One extra observation on LoRAs, since it is the same class of bug. My first pick drifted the entire palette, and its page explained why: it was trained on a different base model from the one I was running. Base model is the compatibility field. Read it first. My second pick matched and still carried its own aesthetic, which is what the strength value is there to attenuate.

Takeaway

Registry rank answers "what do most people use." It does not answer "what satisfies my spec." When your input is unusual, the default that ships with the tool is a legitimate baseline, and the cheapest experiment you can run is to try it before you spend ten decisions replacing it.

The finished artifact was a character sheet: three views, three scenes, three detail crops, all resolved from one paragraph.

If you want to try this with a character of your own, you can start here.

Symmetry Is the Default Your Character Spec Has to Survive

Merl Merl — Sat, 01 Aug 2026 08:39:30 +0000

Character consistency in image generation is usually discussed as an aesthetic problem. I find it more useful to treat it as a contract problem: I hand a model a specification, and I want to know whether the specification survives a change of inputs. So I built a spec with a deliberate failure mode and ran it through two anime image models on the same day.

The failure mode is symmetry.

The spec

Seven attributes, written once, held constant across every run.

character: Shiori
hair:        jet-black, low knot at the nape
hair_pin:    single thin gold pin, through the knot
eyes:        pale grey
face_mark:   small beauty mark, below RIGHT eye
outfit:      black high-collared tailcoat, gold piping, burgundy lining
shirt:       white wing-collar, burgundy ribbon tie
glove:       LEFT hand only
ring:        gold, RIGHT index finger, on bare skin

Five of these are cheap. Hair color, eye color, and a palette are the kind of thing a diffusion model reproduces almost by accident, because they are global properties of the image.

Two of them are expensive, and they are the assertions that matter:

glove_hand == LEFT and ring_hand == RIGHT
face_mark_side == RIGHT

Both are asymmetric. Asymmetry is the interesting test because symmetry is the prior. A model that has stopped tracking your description will not produce noise; it will produce the average, and the average of "one glove" is either two gloves or none, or both attributes collapsed onto whichever hand it happened to render.

There is a third assertion that turned out to matter more than I expected, and I did not write it down at first:

both_hands_in_frame == true

An attribute you cannot see is an attribute you cannot verify, and a model that crops the frame has silently deleted your test.

Test 1: baseline, prompt only

Model A is the Niji Journey model, currently Niji 7. Model B is Tsubaki.2 on PixAI, a diffusion transformer, which matters later because bracket weight syntax like (tag:1.3) works on SDXL-family models and does nothing on a DiT.

Both baselines passed the expensive assertion. Glove and ring landed on separate hands. Model A mirrored the sides, which is a known and boring class of failure. Model B put them where the spec said.

Baseline passing is worth stating plainly, because a lot of comparisons stop here and declare a winner on the strength of a first render. First renders are the easy case. The prompt is doing all the work and nothing has been asked to persist.

Test 2: change the inputs, keep the spec

New outfit, new environment, same seven attributes carried into the prompt verbatim: heavy overcoat, knit scarf, rain-slicked street at dusk, full body.

Run	Model	glove/ring separated	both hands in frame	unrequested additions
2a	A	no, merged onto one hand	no, waist-up crop	gold hoop earring
2b	A, identical prompt	no, merged onto one hand	no, waist-up crop	gold hoop earring

Run 2b is the useful one. I repeated 2a byte for byte specifically to find out whether the failure was stochastic or deterministic in effect, and it reproduced. That distinction is the whole engineering point:

A stochastic failure is a retry problem. Loop until green.
A reproducible failure is an input problem. The same prompt will produce the same misreading indefinitely.

The both_hands_in_frame assertion failing is what caused the primary assertion to fail. With one hand cropped out, the model had one surface for two mutually exclusive attributes and merged them. My spec had a hole in it, and the tool found the hole.

Test 3: reference as input

At this point the correct move is to stop describing the character and start passing it. Model A exposes a Character Reference control. On Niji 7 it renders disabled, and clicking it emits nothing, no error, no tooltip, no explanation. The references panel offers an image prompt and a style reference.

So I used the image prompt, feeding the passing baseline back in at default weight.

Run	Input	Result
3a	baseline image as image prompt	face fidelity best of all runs, palette bled (jacket lining reappeared as a turtleneck), glove/ring still merged, still cropped

This is the finding I care about. The reference improved everything that is a global property of the image and improved nothing that is a discrete fact about the subject. Treating "reference image" as a single capability is a mistake. There are at least two different contracts hiding under that label, and only one of them carries a specification.

Model B routes this through a separate model rather than a flag on the generation model, which is an implementation detail with a real consequence: the character is created on an anime model and then carried by a reference model, so a style shift between the two is expected rather than a bug. It accepts up to ten reference inputs, which fits how character sheets work, since a character is a set of angles rather than one canonical frame.

Across three scene changes on Model B, the face, the knot, and the gold pin held.

Test 4: adding a LoRA, and its cost

A LoRA is a low-rank adapter, a small set of weights trained on top of a base model. I added a community adapter built for eye rendering, typed its trigger words into an otherwise unchanged prompt, and ran it at 0.7.

It delivered the eye treatment. It also softened the face geometry and added bangs that appear nowhere in the spec. At 0.7, the adapter reached past style and into identity.

The generalizable rule: an adapter is a weighted intervention on the same latent space your character occupies, so strength is a tradeoff between the effect you want and the subject you are trying to preserve. If identity is the priority, the weight is the first knob to turn down.

What I take from this

Three things transfer to anything you build on top of image models.

Put an asymmetric assertion in your spec. It is a one-token change, and it converts a subjective "does this look like her" into a boolean. Symmetric attributes will pass even when the model has stopped listening.

Assert your frame. An attribute outside the crop is untested, and an untested attribute fails silently. Naming the framing explicitly fixed more for me than any prompt-weight trick.

Distinguish description from identity. A prompt is a description and descriptions are satisfiable by more than one subject. Persistence needs the character passed as data, either as reference input or as trained weights. Anything short of that is a retry loop with a fixed point in the wrong place.

The tooling question resolves along the same line. If the deliverable is one image, the model with the better first render wins, and in my runs that was Model A. If the deliverable is the same subject across many images, what matters is whether the platform gives you a path to pass identity as data, and that is why the second half of my day happened on PixAI.