DEV Community: Merl Merl

I Scoped an AI Edit to Panel 1 and Got a Diff in Panel 4

Merl Merl — Thu, 08 Oct 2026 20:19:03 +0000

I wanted to know how well an AI model handles a full manga page as one unit: four panels, two speakers, and two short lines of dialogue that belong in specific bubbles. So I wrote the page as a spec and generated it with Tsubaki.3 on PixAI. Then I patched it through a chain of edits in PixAI Studio and checked each output the way I would check a diff.

In the first run, most of my assertions passed. The edits were where I found side effects outside the declared scope.

The fixture

The test page is a karaoke grudge match between two characters with deliberately different silhouettes, so a swapped identity or a misattributed line would be visible at thumbnail size.

page:
  style: black-and-white manga, ink lines, screentone
  layout: [wide, half + half, wide]
  reading_order: left-to-right, top-to-bottom
characters:
  genzo:  {build: short and round, hair: tall white pompadour}
  fumiko: {build: tall and thin, hair: high bun, glasses: true}
panels:
  1: {shot: wide,     speaker: fumiko, line: "BEAT 98, OLD MAN.", screen: blank}
  2: {shot: close-up, speaker: none}
  3: {shot: low angle, speaker: none}
  4: {shot: medium,   speaker: genzo,  line: "YOUR TURN.",        screen: "100"}

The real prompt was plain English, one paragraph for the page rules, one for each character, then one numbered paragraph per panel. The YAML above is only the structure I tested against. Each panel differs from the previous one in exactly one variable (shot, action, or speaker), so I could check each assertion on its own.

First run: four versions, eight assertions

I generated four versions in one batch with Prompt Helper off, so the model received the prompt unchanged. Then I checked each version at three to four times its size.

Assertion	Pass rate
Four panels in the declared layout	4/4
Panel order matches the spec	3/4
Both lines spelled exactly	4/4
Panel 1 tail aimed at Fumiko	0/4
Panel 4 tail aimed at Genzo	4/4
Panel 1 screen blank	0/4
Panel 4 screen shows 100	3/4
Fumiko's cup tipped over in Panel 4	3/4

The two failing rows are both in Panel 1. In every version the text was correct, the bubble was clean, and the speaker was wrong. The model also put an unrequested score on the screen: 190 once, 100 twice, and "10 0" once. With a 100 in Panel 1, the reader knows the result of Panel 4 in advance.

I picked the version with the cleanest Panel 4 as the base for editing.

Patching in PixAI Studio

In PixAI Studio, every step is a node on a canvas, wired to the image it takes as input. Each edit was a new Tsubaki.3 node with one output. Every instruction had two parts: the change, scoped to one panel, and a keep list naming what must stay the same.

Node	Intended change	Change made	Side effects
2	Panel 2: new expression	yes	Genzo gained glasses like Fumiko's
3	Panel 3: two background customers	no	Panel 1 face and lettering changed, page shrank
4 (from 2)	Panel 2: remove the glasses	yes	Fumiko's Panel 1 expression changed
5	Panel 1: move bubble, blank screen	bubble yes, screen no	Panel 4 screen cleared, Panel 1 screen removed
6	Panel 4: restore the 100	yes	both teacups changed

I dropped Node 3 and branched again from Node 2, so the final page is the output of the path 1, 2, 4, 5, 6.

I learned the most from Node 5, where I scoped both changes to Panel 1 and named the 100 in Panel 4 in the keep list.

In Panel 1 only, make two changes. Move the speech bubble that reads
"BEAT 98, OLD MAN." to the upper left of the panel, above Fumiko ...
Make the score screen on the wall dark and blank ...
Keep Panel 2, Panel 3 and Panel 4 exactly as they are, including ...
the number 100 on the score screen in Panel 4 ...

The model moved the bubble as asked. For the screen, it ignored the panel scope: it removed the one in Panel 1 and emptied the one in Panel 4, although the keep list named the 100 explicitly. From the outside, this looked like a selector that matched every object of the same type on the page instead of the one inside the declared panel. That is an analogy for what I observed, not a claim about how the model works internally.

In Node 6, the model restored the 100 and also edited two other repeated objects: Fumiko's teacup in Panel 1 now floats above a tilted saucer, and a second cup appeared in Panel 4.

What I would put in a checklist

Run a batch and assert per panel. With a single version, I could not have seen that the speaker error appeared in all four.
Treat speaker assignment as its own assertion. A line can be spelled correctly and still be in the wrong character's bubble.
Give a bubble a position on the page, together with the speaker's description. In my one run of this fix, the model moved it to the right character.
Diff the whole page after every edit, including panels outside the scope. In this test, the model changed Fumiko's face, the score screen, and the teacups in panels outside the target.
Branch when an edit fails. If I had continued from Node 3, its unrequested changes would have been in every later step.

Untested idea for the next run: when an object appears in several panels, address the target by its position on the page as well as by its panel number.

The finished page is readable from top to bottom, and I kept the two teacup changes on it as evidence. If you want to run the same experiment on your own four-beat scene, you can try it on PixAI.

Integration-Testing an Anime Character on Tensor.Art and PixAI

Merl Merl — Mon, 28 Sep 2026 11:07:02 +0000

A single good anime image is a unit test. A character you want to reuse is an integration test: the same spec has to pass after generation, after a structured layout, and after two edits in a row. I ran that integration test on Tensor.Art and on PixAI with Tsubaki.3, PixAI's newly launched anime model, and logged every assertion.

Setup

Stage	PixAI	Tensor.Art
Generation	Tsubaki.3, Prompt Helper off	WAI-illustrious v17 checkpoint, platform defaults
Reference	image in the prompt box (`@image1`)	IP-Adapter (ControlNet)
Edits	Tsubaki.3 nodes in PixAI Studio	FLUX.1 Kontext Dev in the Edit tab

On both platforms, I used only features that are also open to free accounts. Tensor.Art generated two images per run in this setup, since four-image batches need its Pro plan.

The fixture

hair_and_eyes: copper-red short spiky high ponytail, gray-green eyes
outfit: sleeveless navy coverall, yellow exoskeleton, hazard stripes on shoulder yoke
asymmetric_detail: armor plate missing on the rig's left forearm, blue pistons exposed
small_detail: single gold stud, right ear
scene: exoskeleton lifts a cargo container with both mechanical arms

Stage 1: generation

Assertion	PixAI	Tensor.Art
hair and eyes	pass	partial (mismatched eyes)
outfit and palette	pass	partial (no stripes on yoke)
left-forearm panel	pass	fail (right forearm)
right-ear stud	pass	fail (dangling, left ear)
rig lifts the container	fail (her own hands)	fail (no lift)

Neither platform passed the scene assertion, and the results diverged on the trait assertions.

Stage 2: structured output

The layout spec was an expression sheet: two rows of three, six named emotions in fixed cells, no text. PixAI's character consistency guide lists a reference image and a repeated description as separate methods, and I passed both.

Run	Result
PixAI, reference + text	2x3 grid, 5 of 6 emotions in place, visible traits in all cells
Tensor.Art, IP-Adapter 1.0	single blurred figure (this run also had two setup errors of mine)
Tensor.Art, IP-Adapter 0.6	about 11 faces in overlapping cells
Tensor.Art, text only	clean 12-cell grid, all emotions present, costume changed

When I removed the reference add-on and kept the same text, the image came out clean, which points to the reference step in this setup. With one run per setting, I treat that as a lead, not a proof.

Stage 3: edits as patches

I started both edit chains from each platform's own Stage 1 image. In Edit 1, I asked for a new pose and a laugh and listed every trait to keep. In Edit 2, I used the Edit 1 result as input and switched the floodlights off, leaving an orange beacon as the only light.

Think of each edit as a patch. With a good patch, only the requested lines change, and the rest of the file stays as it was.

Check	PixAI (Tsubaki.3)	Tensor.Art (FLUX.1 Kontext Dev)
Edit 1 requested change	applied	laugh applied, container step had nothing to act on
Edit 1 unrequested diff	pose to kneeling, rig leg became an arm, pistons switched sides	new crouch, both eyes green
Edit 2 requested change	lights off, blue shadow	frame darkened to about a third of its brightness
Edit 2 unrequested diff	beacon moved, window reshaped, containers became cabinets	almost none

I got opposite results from the two chains. Tsubaki.3 applied each change and touched extra lines along the way. The Tensor.Art editing model touched a few extra lines and applied less of the requested change. In a third PixAI edit, I asked for a high camera angle, and the container disappeared entirely. That is the point where I would regenerate from the spec instead of patching again.

Run count

I needed four runs on PixAI for the four steps and six on Tensor.Art, with both extra runs spent on the Stage 2 sheet.

Takeaways for your own pipeline

Write the spec as data and assert on every property after every stage.
Include one asymmetric detail, since a left-right mix-up is easy to spot.
Test reference settings on a throwaway run before a structured layout depends on them.
Diff each edit against its input, and regenerate from the spec once unrequested diffs pile up.

If you want to run the same three stages on your own character, you can start on PixAI.

Flat Tag Lists Leak Attributes Between Characters: Testing Two Anime Generators

Merl Merl — Sun, 27 Sep 2026 12:02:01 +0000

I wanted to know whether an anime image generator could keep a character's small details intact across a whole workflow, so I treated the character like a test fixture and ran the same suite on two platforms: PixAI with Tsubaki.3, and SeaArt with a popular community anime checkpoint plus SeaArt's own reference and editing tools. On both, I only used features that free accounts can also use.

I expected to separate the two platforms by image quality. Instead, I kept tracing failures back to one question: how does each prompt format bind attributes to the right subject?

The fixture

The character is Aldric, a clumsy wizard who cooks for an adventuring party. His spec:

character: Aldric
hair: ginger, short ponytail
beard: short, ginger
eyes: pale blue
robe: mustard yellow, hood down, sleeves cut at the elbow
belt: wide, brown, exactly 3 wooden spoons
prop: crooked wooden wand
legs: cream trousers, rust brown boots

The spoon count is the assertion I trusted most. A face can look right by accident, while three spoons are either on the belt or missing.

The suite

I fixed the budget before the first run: one batch of four images per new scene, one allowed prompt revision for the whole suite, and up to two tries per edit step.

Case	Input change	Assertion
A. Create	baseline	all spec fields present
B. Crowded scene	second character, eight requirements	every attribute on the correct person
C. Reuse	two new scenes from a reference image	spec fields unchanged
D. Edit twice	outfit change, then setting and light	change applied, everything else unchanged

One spec, two serializations

Tsubaki.3 reads plain sentences. The checkpoint on SeaArt expects comma-separated tags. So I wrote the same spec in two formats.

PixAI:  "...a wide brown leather belt with exactly three wooden
         spoons tucked into it, cream trousers, and rust brown boots..."

SeaArt: "...wide brown leather belt, three wooden spoons tucked in
         belt, cream pants, brown boots..."

Results

Assertion	PixAI, Tsubaki.3	SeaArt, community checkpoint
3 spoons, case A	4 of 4	0 of 4
Crooked wand, case A	4 of 4	0 of 4, walking staff instead
Attributes on the correct person, case B	4 of 4	1 of 4
3 spoons, case C	5 of 8	1 of 2
Edit 1 applied, rest unchanged	yes, first try	yes, first try
Edit 2 applied	yes, relit for the new scene	background changed, lighting unchanged

Case C on SeaArt has two images instead of eight because I ran its Character Reference with one image per run.

Why tag lists leak

SeaArt had the most trouble with case B. In three of the four SeaArt images, the model mixed up the two characters: one image split Aldric into a gray-bearded man and a ginger-haired woman in his robe, and another put the robe on a black-haired stranger.

As an analogy, think of a tag prompt as one flat array with no object boundaries:

// tag prompt: every attribute in one list, no owner
["1boy", "1other", "ginger beard", "mustard yellow robe",
 "black bob hair", "grey hooded cloak", "holding empty wooden bowl"]

// sentence prompt: attributes scoped to their subject
{
  wizard:    { beard: "ginger", robe: "mustard yellow" },
  companion: { hair: "black bob", cloak: "gray", holds: "empty bowl" }
}

In the flat version, the model has to infer which attribute belongs to which subject. In the scoped version, I answer that question in the prompt itself. This is a mental model for writing prompts, and I am not describing either model's internals.

The one revision

Tsubaki.3 still missed two requirements in case B, in all four images: the cauldron was supposed to float above the fire, and noodles were supposed to hang from Aldric's beard. The Tsubaki.3 Prompt Guide recommends describing spatial relationships in full sentences, so I gave each missed detail its own sentence and left everything else untouched:

The cauldron hovers in mid-air by magic, with a clear gap of empty air
between its round bottom and the tips of the flames, and nothing holds it up.

Both assertions went from 0 of 4 to 4 of 4. One unrelated assertion regressed: the three carrot slices on the cave wall appeared in 2 of 4 images before the change and in 0 of 4 after it. I logged that as a side effect of the rewrite.

Reuse copies state you did not ask for

For case C, I gave PixAI the first image as a reference in the prompt box and described only the new scene. Face, beard and bare head matched in all eight images. A leather pouch that I never specified in case A also appeared in seven of the eight, because it was in the reference image.

SeaArt's Character Reference showed the same behavior in a different form. In the reading scene, it copied the reference background, chests and fire included. In the river scene, the belt count went from three spoons to five or six.

I now treat a reference image as a snapshot of state. Everything in it is input, including accidents.

The edit chain as a pipeline

Case D had two steps: add a stew stain to the robe, then move Aldric to a sunset hillside. I used the stain as a canary value. If step 2 had used the original image instead of the result of step 1, the stain would have disappeared.

On PixAI, I linked the steps as nodes in PixAI Studio, with Tsubaki.3 in every node. The stain stayed through step 2, and Tsubaki.3 relit Aldric for the sunset, with a small drift: a new smear on his cheek and a slightly different wand.

On SeaArt, the stain also stayed, and Aldric came through step 2 almost pixel-identical. The lighting on him did not change, so he looks out of place in the new scene. SeaArt also returned the first edit at a smaller size than the input, 864 pixels wide instead of 1152, and its reference and editing windows have no negative prompt field.

What I would reuse

Write each subject as its own sentence block when the model reads sentences.
Put one countable detail in every character spec. With it, "looks about right" becomes a pass or fail.
Use a canary value in multi-step edits to confirm which image each step used as input.
Check the reference image for accidents before reusing it.

If you want to run the same suite on your own character, you can start on PixAI.

Unit-Testing an Anime Prompt: Nine Assertions on a Civitai Alternative

Merl Merl — Tue, 22 Sep 2026 20:41:24 +0000

The anime model I tried on Civitai this summer used tag lists, and for hard poses, model-library workflows offer pose-guide add-ons such as ControlNet, which PixAI also offers on its other models. Tsubaki.3, PixAI's newest anime model, takes full sentences and also handles references and edits in the same model. I wanted numbers instead of impressions, so I treated each prompt like a test case: a fixed spec, a batch of four, and a pass count for every requirement.

Setup

Model: Every run used Tsubaki.3, with batches of four for new scenes and single images for edits.
Preprocessing: I switched off Prompt Helper, PixAI's automatic prompt rewriter, so each result reflects my own wording.
Extras: I used no style preset, no Recipe and no LoRA.

The fixture

The character is Sorane, a street dance crew captain I created for this test. Her spec had seven checkable traits:

hair: tangerine bob, undercut on the right side
eyes: teal
face_mark: small black star tattoo under the left eye
jacket: oversized lime track jacket, exactly 3 white chest stripes, off the left shoulder
top: black tank top
legs: charcoal cargo joggers, red bandana on the right thigh
shoes: white high-tops, red laces

In the first batch, eyes, star, tank top, bare shoulder, bandana and sneakers passed 4/4. The stripe count passed 1/4. The undercut side failed 4/4: it landed on her left, next to the star. I kept the image with three stripes as the fixture for every later test.

Test 1: a hard pose from text alone

In the next prompt, I described a two-person breaking battle: Sorane upside down on one hand, a silver-haired opponent mid-jump on the right, a floor-level wide-angle camera, a dark crowd, two crossing spotlights and puddles.

Assertion	Passed
upside-down one-hand pose, knees bent	4/4
opponent mid-jump, knees tucked	4/4
left and right placement	4/4
colors stay with their own character	4/4
no feature copied to the other character	3/4
crowd as dark silhouettes	3/4
spotlight beams crossing	1/4
shadows falling toward the camera	0/4

The pose and placement passed from text alone. The lighting assertions failed most often.

Test 2: nine assertions in one prompt

I stacked nine requirements into the staircase prompt. I asked for the seven traits, a mid-air jump down the stairs, an open-mouthed laugh, a high camera and a corner-to-corner staircase. I also asked for exactly five cones in a row, a blue "EXIT 7" sign, rain on wet steps, and one yellow streetlamp near the top-right corner throwing her shadow toward the lower left.

Assertion	Passed
jump, laugh, high angle, rain	4/4
lamp near the top-right corner	4/4
shadow toward the lower left	4/4
wet, reflective steps	3/4
sign with clean "EXIT 7" lettering	1/4
exactly five cones	1/4 (counts: 4, 4, 5, 4)
staircase running corner to corner	0/4
lamp as the only light source	0/4

Compare the shadow rows across both tests. In Test 1, I named two spotlights on the pillars but gave them no place in the frame, and the shadow assertion failed 0/4. In Test 2, I named one lamp, its position in the frame and the shadow direction, and it passed 4/4. PixAI's Tsubaki.3 prompt guide recommends naming the light source, and these two runs are consistent with that.

I also tried isolating the failing assertion. On the image with the clean sign, I ran one edit, asking only for five cones in a straight, visible row. The row came out straight and visible, and it still had four cones.

Test 3: the reference image as a fixture

Tsubaki.3 takes a reference image in the prompt box, called @image1 in the text. I passed the fixture and described only the change, following PixAI's own advice: a rooftop at sunrise, then a waist-up studio shot in blue evening light, four images each.

Check across 8 images	Result
star tattoo under the left eye	8/8
undercut at reference size	2/8 (grew into a half-shaved head in 6)
jacket hue close to reference (studio set)	0/4 (darker, cooler green)
unrequested sleeve stripe from the reference	about half

The stripe in the last row was never in my prompt, yet it came back in about half of the new images. In my runs, accidental details in a reference were copied like intended ones.

Test 4: edits as patches

I applied two edits in sequence. In the first, I swapped only the jacket for a crimson satin bomber and listed everything to keep. It worked on the first run, with four side effects: the jacket hung open, the tank top became a T-shirt, one hand moved into a pocket, and a drawstring appeared on the joggers. With the second edit, applied to the first result, I moved her into a night scene. The setting, light and shadow direction passed, while the red laces turned white and the drawing style shifted.

What I would tell another developer

Write scene requirements as sentences, and test each one separately across a batch.
Make lighting assertions specific: source, position and shadow direction.
Treat exact counts as unreliable and check them by hand.
Diff every reference-based result against the reference, including details you never asked for.
Keep edits narrow and check for side effects after each one, since both of my edits had some.

If you want to run the same kind of test on your own character, start with a written spec and a batch of four on PixAI.

Treating an AI Anime Character Generator Like a Function With Default Arguments

Merl Merl — Mon, 21 Sep 2026 12:48:40 +0000

Tsubaki.3, the newest anime model on PixAI, is now officially released, and I used the release week for a small controlled test. I took one original character from a three-sentence spec to a design I would keep developing, changing one layer at a time and logging what each step changed. If you think in code, the process maps neatly onto a function call with default arguments.

Setup

Subject: Kazane is a broom-racing witch I created for this test.
Model: Every run used Tsubaki.3, with batches of four for the text-only runs and single images for the reference runs.
Preprocessing: Prompt Helper was on in every run. It rewrites the prompt before generation, and each image's detail page shows the rewritten version next to the original.
Out of scope: I skipped LoRAs. PixAI's model vs LoRA explainer covers when one is worth adding; my questions were about individual clothing pieces.

Run 1: most arguments unset

In the first prompt, I passed three values and left everything else open:

generate_character(
    role="loud, competitive witch who races brooms between floating islands",
    hook="flies bareheaded, anything on her head would slow her down",
    style_note="dressed for speed rather than for a storybook",
    # hair, eyes, outfit and footwear were never passed
)

Check	Batch 1
Recognizable anime witch on a broom	4/4
Bareheaded, as specified	1/4
Anything resembling racing gear	0/4
Looks like an adult in her twenties	0/4
Distinct hair colors	4

The unset arguments resolved to the most familiar version of "witch": pointed hats, dark robes, school uniforms and red ribbons. In three images, that default replaced a value I had passed explicitly. The spec described a bareheaded racer, and three of the four images showed the stock witch instead.

Run 2: pass the values explicitly

I treated the batch as a diff to review. I kept the bareheaded image, the shouting expression and the trailing fabric. I rejected the hat, ribbon, robe and skirt, and I replaced the reddish hair and the teenage look. Then I appended each decision to the unchanged original three sentences:

generate_character(
    ...,  # the original three sentences, verbatim
    head="top of her head and full hairstyle visible",
    hair="deep plum, single high ponytail",
    eyes="golden yellow",
    top="fitted midnight-navy racing top with a zip",
    capelet="short, teal, right shoulder only",
    legs="black trousers tucked into white knee boots",
    broom="exactly three teal bands",
)

The head argument describes what must be visible instead of passing a negative flag like "no hat". Batch 2 changed many values at once, so I cannot credit the bare head to this line alone. The head stayed bare in 4/4 images, and hair, eyes, top, trousers, boots and broom bands matched in every image.

Two values still varied because I had left them loose or unset. The trailing fabric came out navy three times and teal once, and the broom handle's end changed shape. The pose also repeated across all eight images: she hovers over a rock ledge instead of riding the banked turn I asked for.

Run 3: images as arguments, and the scope bug

Tsubaki.3 accepts two reference images in the prompt box, addressed as @image1 and @image2. I passed the refined character as @image1 and a photo of a monarch butterfly as @image2, then compared two scopes:

# wide scope
redesign(target="outfit", pattern=image2)

# narrow scope
redesign(
    target="capelet and its trailing fabric",
    pattern=image2,
    keep=["navy top", "black trousers", "white knee boots"],
)

Run	Pattern source	Scope	Result
A	butterfly	whole outfit	pattern on the entire suit; top, capelet, trousers and boots lost
B	soap bubble	whole outfit	swirl pattern on the entire suit; white boots kept
C	butterfly	capelet only	pattern on the capelet; top, trousers and boots kept, one sleeve turned orange

Reading the Rewritten Prompt for run A explained the result. My wide wording became "a fully covering racing suit patterned after the butterfly", so the rewrite kept my wide scope and stated it even more broadly. In the narrow-scope version, the rewrite kept every named item almost word for word. The practical rule: when you pass an image, pass the scope with it.

One more edge case: an earlier attempt that described the capelet's "streaming tail" produced a furry tail beside the fabric. Tokens like tail, wing and horn can resolve to anatomy, so I now describe those pieces as fabric.

Run 4: a style layer as a regression test

Recipes are reusable prompt add-ons in the Tsubaki.3 generator panel, and PixAI Official publishes style Recipes among them. I reran the narrow-scope setup with the Holographic Recipe switched on. Face, hair, eyes and broom bands passed. The outfit scope, the background and the camera distance all changed.

I read that like a failing regression test. The traits that passed are stable enough to build on, and the ones that failed need locking before I explore looks.

What I would tell another developer

Unset arguments get defaults from the role word, and those defaults can override values you did pass.
Describe what should be present instead of passing negations.
Keep the original spec verbatim and append decisions, so each batch is a clean diff.
Pass scope explicitly with every reference image, and read the Rewritten Prompt when a result surprises you.
Check ambiguous tokens like tail, wing or horn before a run.

If you want to run the same experiment on your own character, start with a three-sentence spec and a batch of four on PixAI.

I Ran a Five-Step Image Pipeline Entirely on a Phone

Merl Merl — Wed, 16 Sep 2026 08:41:26 +0000

Most write-ups about mobile AI image apps stop at the first generation. That is the easy case. The interesting question is whether a full pipeline runs on a phone: generate, swap the model, condition on a reference, edit a region, then retrieve the artifact later.

I ran that pipeline end to end in the PixAI mobile app, on an iPhone, with the laptop closed. Below is the setup, the controls, and what each step produced.

The fixture

The prompt runs to about a hundred and twenty words and describes a character and a scene: subject, clothing, pose, environment, light direction, camera position. Five visual identifiers in the description that are easy to check in an output:

Identifier	Description
Hair	copper-red, cropped
Jacket	dark green band jacket with a wide cream diagonal sash
Undershirt	black, high collar
Trousers	cream with a single green side stripe
Prop	brass tuba

Everything else varied one axis at a time.

Step 1: baseline generation

The generate screen puts LoRA, model, style, mode, output size, and quantity into one horizontally scrolling row under the prompt card. One run returned four images at the quantity setting shown.

The bottleneck is text entry, not compute. With the keyboard open, the prompt field is a few lines tall, so proofreading a long description means scrolling inside a small window. If you build prompts programmatically or keep them in a notes file, paste them in rather than typing.

Step 2: model swap, seed held constant

The second run used the same prompt string and the same seed on a different base model. A seed fixes the random starting point, so holding it constant removes one variable.

The model picker has three tabs: Preset for official models, Collection for saved ones, and Market for community uploads. Every card is labeled with its architecture family, so DiT.2, DiT.1, or XL, which is the practical signal for what kind of prompt the model prefers. The swap took three taps, and the session continued without a restart.

Assertion	Result
Written identifiers reappear on model B	Pass, all five
Face and proportions match model A	Fail
Rendering style matches model A	Fail
Same seed reproduces the composition	Fail

The last row is the one that changes how you store a character definition. A seed indexes noise inside one model. Across two models, the same integer produced no resemblance at all. Prompt text is the portable part of a character definition, and the seed is not.

Step 3: reference conditioning

The reference workflow is exposed as a preset in the model list rather than as a separate mode, which means selecting it replaces your base model selection. Worth knowing before you plan a session around it.

The panel enforces an order: the image loads first, and the prompt field stays inactive until it does. I had a paragraph ready and could not enter a character of it until the reference was in place.

The input came from the camera roll, where the previous step had already saved it. That is the structural argument for doing this work on a phone. The source artifact and the output destination are the same device, so the file transfer step disappears.

Conditioning on the earlier output plus a short new-scene description returned the same character in a different location. Hair, sash, collar, and instrument came back intact, with nothing about the character repeated in the prompt.

Step 4: masked edit

Edit opens a canvas with Inpaint and Outpaint as separate tabs, and mask size, brush, eraser, mask shape, and feather along the bottom. A small box in the corner previews where the masked region falls on the image.

I masked one element and requested a change there. Measured against the source file, the marked band came back about a third wider at mid-chest, while the buttons, the hand, the mouthpiece, and the collar were unchanged. Whatever else you think of the result, containment held: the diff concentrates inside the mask by a wide margin.

Step 5: retrieval

Library opens on a menu of collections, published work and likes, with Recent Tasks below it. Each run is a card titled with the opening words of its own prompt, stamped with a date and time, and the list has a search box above it.

Open a single result, and the next actions are on one screen: Download, Publish, Animate, Edit, Import to Generate, and Re-roll. Import to Generate pulls that run's prompt and model back into the generate screen, which is the resume-session path.

What a phone is bad at

Long prompt editing, because the visible field is small. Comparing several outputs at once, because a run returns thumbnails, and judging them at full size means opening one at a time. Detail review, because a small display hides errors: one of my outputs has a clearly elongated forearm that I only noticed on a laptop. And finding a rarely used control, since there is less room off the main path.

Verdict

The pipeline ran five steps on one device with no restarts, end-to-end on a phone, and the constraints are input and review rather than capability. If you want to run the same test, four checks matter: the model picker has to expose metadata, the reference input has to accept a local file, the editor has to respect a mask, and the history has to be searchable.

For where each control is in the interface, the PixAI app guide covers it screen by screen: https://blog.pixai.art/en/pixai-app-guide/

Try the same pipeline on PixAI and see how far your phone takes you.

Free tier, real workflow: what I learned testing an anime image generator on one character

Merl Merl — Sun, 13 Sep 2026 09:12:58 +0000

Most write-ups about free image generation stop at the credit count. That number tells you almost nothing, because what decides whether a free tier is usable is how much of the pipeline it exposes and where it hard-stops.

I ran a session on PixAI to find out, using one original character as a fixed test subject and staying on features a never-paid account can reach. Three findings are worth passing on, and all three are the kind of thing you only hit by actually running the thing.

The setup

The subject was a surfer with a deliberately over-specified design: turquoise streak on the left of the hair, green eyes, short asymmetric wetsuit with the right arm bare, orange leash on the left ankle, beaded bracelet on the right wrist, shell earring on the right ear, board with three stripes. That gives seven checkable attributes, several of them side-specific and one of them countable.

That is a test harness, not a character sheet. Side-specific and countable attributes fail visibly, which means you can grade an output instead of squinting at it.

Finding one: prompt syntax belongs to the model family, not the platform

The platform hosts two architecture families. The DiT models parse natural-language sentences. The SDXL-derived models respond to tag-style input. Running the same character through one model from each meant rewriting the prompt, not swapping a dropdown.

The rewrite is where things broke. Hair color, the streak, and the eye color carried over. Everything else drifted:

orange ankle leash on left ankle rendered as orange boots on both feet
the three board stripes vanished entirely
the shell earring became a turquoise stud
right shoulder and arm bare collapsed into a bare shoulder with both sleeves intact

Some of that is the model, and some is my tag translation, and I cannot cleanly separate the two from one test. The transferable point stands either way: switching model families is a prompt rewrite, and every attribute you care about needs re-anchoring in the new syntax. Treat your prompt as source coupled to a target, not as portable input.

Finding two: LoRAs are architecture-bound dependencies

LoRAs are small adapter files that steer a base model toward a specific style, outfit, character, or concept. Free accounts can load them into normal generation, which is the part that makes a free tier interesting rather than decorative.

The dependency behavior is the useful bit. Each LoRA is trained against a specific base model and loads only onto matching ones. The browser has no architecture filter, so the ecosystem solved it socially: creators write the architecture into the LoRA name. Searching dit.2 returns results literally named Yuu_style DiT.2, BotanInk(DiT.2), ColorSnapVibe(DiT.2).

Every LoRA card carries a base model field, and loading the LoRA sets that base model for you. The consequence is worth stating plainly: your adapter choice determines your base model, so on a free account part of your control decision resolves before you generate anything.

One more practical note. The first adapter I picked had a trigger word list running to nine separate instructions, all of them about eyelashes and under-eye detail. The model obliged by building an extra eye onto the character's cheek. Read the trigger list before loading, the same way you would read a package's peer dependencies.

Finding three: a seed does not survive a mode change

The platform offers two generation modes, both open to free accounts, differing in cost and compute. I assumed the cheaper mode would give me the same image at lower fidelity, so I ran one prompt through both with the seed pinned.

It gave me sibling images, not the same image at two quality settings. Measured on a coarse layout comparison, the pair sat inside the same similarity range as two other outputs from the same batch. The prompt explains the resemblance; the seed contributed nothing measurable across the boundary.

That has a workflow implication. If you explore cheaply and find a composition you like, you cannot promote it to the expensive mode by reusing the seed. The modes are separate generations, so explore in whichever mode you intend to finish in.

Where the two modes did differ was background detail. The water carried noticeably less fine texture in the cheaper mode while the face barely changed. One pair is thin evidence for a rule, so run the check on your own subject before committing a day's budget.

What the free tier actually gates

Two categories get conflated constantly, and separating them is most of the analysis:

Unavailable without paying. The fastest generation queue, the video tools, the reference-based consistency tools, and a monthly adapter training allowance. The membership and payment information page carries the specifics, and it is worth reading rather than trusting my summary.

Available, and metered. Everything else. That covers both generation modes, the public model library, community adapters and the standard image sizes. Lean on any of them and the daily allowance drains faster, which is a budget constraint rather than a wall. The free credits guide covers the refill mechanics.

The part I did not expect

I assumed the first generation would be the best one and everything after would be cleanup. The opposite happened. My character's description never fully landed until the fourth stage, after the model and the adapter were settled and the scene had changed completely. The final image carried every specified attribute at once, including the countable one.

For anyone benchmarking a free tier, that is the measurement worth taking. A tier that produces one good image and locks the door behind it is a demo. A tier that lets you converge across four generations is a tool, and the convergence is the thing to test.

The whole session ran to roughly a dozen generation jobs across four configurations, entirely on the free side. If you want to reproduce the method, the platform is here. Pick a subject with side-specific and countable attributes, and grade the outputs instead of admiring them.

An Anime Image Model Is a Flaky Dependency, So I Asserted on Every Property Twice

Merl Merl — Thu, 10 Sep 2026 16:11:10 +0000

Image models are nondeterministic functions. Same input, different output, and the variance is controlled by a seed you can pin. Anyone who has written tests against a flaky service already knows what that implies: a single call proves nothing. You need a second call with one variable changed, or you are reading noise as behavior.

The comparisons I read mostly skip this. One image per product, results side by side, call it a benchmark. So I ran a proper version on one anime image platform, with a control run for every claim.

The fixture

I built one test character with assertable properties, the way you would design a fixture rather than a mood board:

dark brown bob cut straight at the jawline
pale grey green eyes
a mustard base layer whose left sleeve turns charcoal below the elbow
exactly four tool loops on the right thigh
a charcoal patch on the left knee

Two of those are side-specific, one is countable, two are pure color. Side and count are the ones worth including, because a symmetrical character with no countable elements passes every test by accident.

All runs used the same model, mode and settings, with only the stated variable changed between a run and its control.

Check 1, prompt following with a batch instead of a single call

Ten checkable instructions in one prompt, generated four times with nothing changed but the seed.

Six instructions appeared in all four outputs: the camera framing, which hand held which object, the two-color sleeve on the correct arms, the loops on the correct thigh, the patch on the correct knee, and the eye color. Those are model behavior and you can build on them.

One failed in all four: the requested low camera angle never arrived. The count landed once, as four straps on a tool roll the model invented, and came back as six, seven and six in the others.

I later ran the same prompt four more times with a single color word changed. Across those eight generations, the correct count of four appeared twice. A single sample would have supported either conclusion, which is the argument for control runs in one number.

One more thing surfaced only because there were four outputs. The prompt asked for the object at chest height and for the character to look up. Exactly one output satisfied the first, and it is the same output that failed the second. The model coupled two instructions I had written as independent.

Check 2, state across calls

Same character, two new scenes, fresh prompts.

High-level identity held everywhere. Hair, eyes and the main colors survived without effort. The fine-grained state did not. In both new scenes the camera sat behind the character, and the entire left and right assignment flipped: the mustard sleeve and the loops moved to the opposite side of the body. They stayed on the side nearest the camera, which is where they had been in the original.

If you are generating a comic or a character sheet where handedness matters, that is a real constraint, and you will never see it with a symmetrical design.

Check 3, reference input versus full description

Same scene, same seed, two runs. First with the full written description. Second with the description deleted and the earlier image attached as a reference at default strength.

The reference carried hair, eyes and the main colors with zero description, which is a genuine reduction in prompt length. It dropped the color break at the elbow, so both sleeves came back plain. The loops multiplied.

Large flat regions transfer. Small structural information does not. That split repeated in every check where the character moved between generations.

Check 4, edit versus regenerate

One instruction: change the mustard layer to deep teal, keep everything else, with the preserved elements listed by name including the charcoal sleeve.

The edit held the composition almost exactly and then turned both sleeves teal, erasing the element I had named in the preservation clause, and repainted the knee patch. The output also came back at a smaller resolution than the source.

The control, the original prompt with one word changed and generated fresh, kept every property correct across all four runs and produced a completely different composition.

Regenerating behaved as the method predicts. The edit is the interesting half, because it decides whether you can fix an artifact you already like without losing the parts that made it worth keeping.

What this means if you are evaluating a platform

Treat the evaluation like testing an unreliable dependency. Assert on properties, not on vibes. Run every assertion twice. Pin the seed when you want to isolate a variable and release it when you want to sample the distribution. Count things instead of eyeballing them, and pick a fixture where counting is possible.

I ran all of this on Tsubaki.3 on PixAI, which is anime focused and exposes models, LoRAs, reference input and instruction editing in one panel. The platform's SDXL model guide covers why the older model family behaves differently on prompt syntax, which matters if you plan to mix families.

The numbers above are that platform's numbers. The method is portable, and it takes an afternoon.

If you want to run it, start here and design your fixture with one asymmetric property. That single detail will tell you more than any gallery of cherry-picked samples.

Chaining Image Generations Is a Pipeline Bug: Measuring Drift Across Four Rendering Stages

Merl Merl — Wed, 09 Sep 2026 12:07:16 +0000

If you have ever built a data pipeline where each step consumes the previous step's output, you already know the failure mode: an error introduced at step two arrives at step five looking exactly like a legitimate value. Downstream, both look like ordinary values of the same type.

Image generation pipelines behave the same way, and I measured it.

The setup

The subject is one drawing of an ice sculptor beside a block of ice with a thermos frozen inside it. Four rendering stages, run on Tsubaki.3 in PixAI:

line art -> grayscale -> flat colors -> final render

Every run held these constant:

same seed
same model, no style preset, Pro mode
one image in the Base Image slot
Single generation, no batch, so the measurement reflects instruction following rather than best of four
same instruction shape: one sentence naming the stage, one clause listing what stays fixed

Six identifying details were declared up front, chosen to be asymmetric or countable so that survival is checkable rather than arguable: a braid behind the left ear, a badge on the left collar, four tools on the belt, one glove on the left hand, one sleeve rolled and one down, and the thermos inside the ice.

Loading a base image changes the output size without changing the setting. Runs without a base image came back at 960 by 1280, and the identical setting with a base image loaded came back at 896 by 1184. Trust the size on the finished file.

What held

Composition held almost exactly. Aligning edge maps against the line art, the largest displacement across every base-image run was six pixels on a frame 1,184 pixels tall. All six declared details and the camera angle came through every stage.

Run the same finishing instruction directly from the line art, and edge overlap against the original scores 0.168. Run it from the flat color stage instead, and it scores 0.147. Drop the base image entirely and generate from the text alone, and it scores 0.083, with the composition sitting 31 pixels across and 28 down from where the line art put it.

What broke

The chained final render preserved everything and advanced almost nothing.

Measured on the ice surface, the share of pixels sitting on a hard edge went from 15.8 percent at the flat color stage to 24.7 percent after the render instruction. A finishing pass should be moving in the other direction. The same instruction run directly from the line art brought that share to 3.7 percent, and the ice came back translucent.

In an empty patch of white background, the tonal range ran zero in the line art, two in the grayscale, two in the flat colors, then 52 after the chained render step, filled with a blocky mosaic. That pattern was already present at stage two, sitting at an amplitude too low to see. Four passes later it was the most visible thing in the frame. The direct render, from the same prompt text, left the same patch at a range of one.

Why the topology matters

At stage three the model gave the thermos a pale wood handle. My prompt says nothing about a handle color. At stage four that handle arrived unchanged, in the same shape and the same tone, because by then it was pixels in the input image exactly like everything I had specified.

Each pass behaves as though its input image is the whole story. Chaining therefore promotes every intermediate guess to a fact, and on this evidence the later passes had nothing to separate an instruction from an earlier guess.

Across three renders started from the line art rather than the chain, that handle came out dark red once and grey metal twice. Pale wood appeared in none of them. The two chained stages matched each other exactly.

The refactor

Hold the structural base fixed and generate every treatment from it directly:

                 +-> final render
line art (base) -+-> warm sunset
                 +-> cool moonlight
                 +-> strong backlight

Drift stops compounding, because every step reads the same fixed input. The cost is real: a direct render has no access to the intermediate information, so it reinvents anything the middle stages had settled. In my runs the direct version produced the better finish and dropped details the chain had locked in. From one instruction you get one of the two.

That is the configuration behind the four finishes here, one per lighting condition, with only the light changed between them. Composition held in all four, shadows followed the named source, and the stated local colors kept their hue under colored light in three of the four. Under moonlight the warm bias on the stone wall fell from 23 points of red over blue to under one, which is the one case where the light repainted the surface instead of lighting it.

Takeaways

Treat the earliest artifact that carries the structure as the source of truth, and read from it every time.
Chaining generations is convenient and lossy. Every pass rewrites the entire image, so anything that survives does so by being redrawn the same way.
Lock the seed and change one input at a time, or you cannot attribute any difference you observe.
Declare your checkable details before the run. Asymmetric and countable beats descriptive.

All of the above comes from single generations rather than repeated trials, so treat the direction as the finding and the exact numbers as one sample.

If you want to run the same experiment on a drawing of your own, the model I used is on PixAI.

29 Words on One Locked Seed, and What They Cost the Picture Underneath

Merl Merl — Tue, 08 Sep 2026 08:16:56 +0000

Every guide on getting text into AI-generated images says the same thing: keep it short, keep it big, and hope. That is folk wisdom, and folk wisdom is what you get when nobody isolates the variables.

So I isolated them.

The setup

Think of a text-to-image call as a function with a lot of arguments, most of which nobody holds constant when they benchmark it. Model, seed, aspect ratio, subject description, style, and the actual text instruction all move at once in a typical comparison, and then somebody publishes a conclusion about text rendering.

My setup pinned everything except one argument:

generate(
  model:    "Tsubaki.3",          // fixed
  seed:      <locked>,            // fixed, identical on every run
  ratio:    "3:4",                // fixed
  subject:   <one paragraph>,     // fixed, reused verbatim
  style:     none,                // no preset, no LoRA
  batch:     1,                   // single generation, never best-of-four
  text:      <THE ONLY VARIABLE>
)

That last constraint matters more than it looks. Generating four and picking the nicest one measures your fourth attempt, not the model's instruction following. Every result below is a first and only run.

I also ran a control with the text argument empty, which turned out to be the most informative run of the whole set.

The subject was a woman in her fifties repairing box kites on a coastal dune, carrying four checkable details: short grey hair, goggles on her forehead, a brown patch on the right hip of her apron, and a spool of orange cord on her left forearm. Countable features give you a diff target.

Test 1: two text elements

A title and a subtitle, requested in large capitals in the empty sky at the top.

Both correct. Title cap height 163 pixels, subtitle 31, clean gap between them, nothing overlapping the character.

Test 2: five text elements

Title, tagline, date, a two-line information block, and a corner badge, in one call. I chose the strings so no word repeated anywhere on the poster, which gives you traceability: every rendered string maps to exactly one instruction.

All five elements appeared in the requested positions. Four were correct. The fifth was a small corner block where NINE rendered as NIVE, while NORTH DUNE on the line beneath it came out right.

The hierarchy is the interesting part, because it is measurable rather than a matter of taste. Cap heights, top to bottom:

Element	Cap height
Title	164 px
Tagline	31 px
Date	22 px
Badge	~18 px
Info line 2	17 px
Info line 1	15 px

That ordering matches the importance I assigned each element in the prompt. I never specified a single size. The model inferred the ranking from the semantic role of each string, which is useful behavior if you are generating a lot of layouts.

Note where the error landed: the 15 pixel line, the smallest thing on the poster. Two pixels separate it from the correct line directly below.

Test 3: swap the script, hold everything else

Same seed, same position, same instruction shape, comparable title length. Only the writing system changed.

Latin: correct
Japanese (3 characters, kanji plus hiragana): correct
Korean (4 Hangul blocks): 1 of 4 blocks correct

The Korean failure mode is the one to internalize. All four blocks are valid, well formed Hangul syllables. Spacing is even. Stroke weight is consistent. The output looks completely correct and says the wrong thing.

This is the difference between a crash and silent data corruption, and it has the same implication: you cannot validate this by looking at it, only by having someone read it.

Test 4: relational layout instructions

Three simultaneous position constraints in one prompt, expressed relative to the subject rather than to the canvas: title above her head, date in the lower left, badge in the upper right, all text clear of her face and the kite.

Then the same prompt with one addition: reserve the top third as empty sky.

Run A honored all three positions and put a lowercase i in the middle of an all-capital title, plus a small non-letter mark after the final D.

Run B produced every word correctly and solved the reservation by building something I never asked for: a solid header strip across the top 23.7 percent of the frame with the title set inside it. Her head starts at 34.8 percent, the kite at 36.2, both below the band as requested. The badge left its assigned corner and attached itself to the end of the title.

Across both runs: 15 element position requests, 14 honored.

The finding nobody benchmarks

Here is why the empty control run mattered. I measured the vertical position of the top of the character's head as a fraction of frame height:

Run	Head position
Control, no text	25.7%
Layout run A	28.2%
Japanese	33.0%
Five elements	34.2%
Korean	34.7%
Layout run B	34.8%
Two elements	35.0%

Same seed on every row. Every run carrying text pushed the subject lower and made it smaller, by 2.5 to 9.3 percentage points.

The text is not composited over a finished illustration. It is drawn in the same pass, out of the same frame budget, and the artwork is what gets compressed to make room. In run B a quarter of the output stopped being a picture entirely.

If you are generating assets programmatically, this is a real constraint on your pipeline: you cannot add a text argument and expect the visual to stay put, and you cannot fix a bad string with a retry without rebuilding the composition around it.

Aggregate results

29 Latin words requested, 27 rendered exactly
2 failures: one wrong letter, one case defect
Large display type: correct in 100% of runs
Both failures at small size or under heavy layout constraints
Japanese correct, Korean 1 of 4 blocks
15 position requests, 14 honored
Hierarchy correctly ranked in every layout, unprompted

What I would ship

Generate the composition and the headline together, since that is where the model is strong and where it does work you would otherwise do by hand. Treat every returned string as untrusted input and read it character by character. Set fine print, dates, prices, and anything legally fixed in an editor afterward. And never ship a script you cannot read without a human check, because the failure mode there is invisible.

Short display text is close to solved. Everything below about 20 pixels of cap height is still yours to handle.

You can run the same test on your own character at https://eap.pixai.art/go/balazs

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