DEV Community: Merl Merl

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

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.