Speed, Checkerboard Noise and Drift Are Three Different Problems

Three things go wrong when you push an image model into daily production, and they feel like one problem. The render is slow. The result has a faint checkerboard in the flat areas. The face is two pixels off from where it was in the reference. All three show up in the same session, so the instinct is to reach for one fix, usually the one with "turbo" in the name, and then wonder why two of the three problems survived.

Ai-Hakase, the Japanese creator who documents ComfyUI graphs with measured timings, published a follow-up to her Qwen Image 2.1 write-up on 16 October that is organised almost entirely around separating those failures. The framing is worth stealing even if you never touch Qwen: speed, texture, and geometry belong to different layers of the stack, and a fix applied at the wrong layer buys nothing and hides the diagnosis.

Her workflow files sit behind a paid membership, which is worth stating because the reasoning is public and the clickable graph is not. The conclusions below are hers; the diagnostic order is mine.

Layer one: throughput

Her main line is the official Turbo variant at eight steps. Not four, not a two-step experiment. Lightning, in her split, is for drafts, GGUF is the switch for low-VRAM machines, and the few-step accelerations that circulate in the community are deliberately left out of the recommended path.

The rule underneath that choice matters more than the numbers: run one accelerator, not several. Stacking a turbo LoRA on a turbo checkpoint, or adding a second step-skipping method on top, changes the sampler's effective schedule in ways that are hard to reason about and almost impossible to attribute afterward. When output is bad, you no longer know which of the three accelerators caused it. She also notes that Spectrum, a prediction-skipping method for many-step sampling, does essentially nothing at eight steps, which is a useful example of a tool that is real but irrelevant to this particular configuration.

Her reported timings, on her own hardware and with her own settings: roughly seven seconds around one megapixel, roughly seventeen seconds near 2K, generally inside twenty seconds. Treat those as an existence proof rather than a benchmark. They are one machine, one graph, one author's judgment about what "quality" means, and the post is two weeks old in a stack where nodes change weekly.

The honest quality question with eight steps is not whether it is fast. It is whether the failure modes you get at eight steps are the ones you can see before a client does. Her position is that for the edits she does, they are.

Layer two: the checkerboard

The grid pattern is the most misdiagnosed of the three. It gets blamed on the upscaler, on the sampler, on the sigma schedule, on the LoRA. Her answer is more specific: the checkerboard in Qwen Image work usually originates in the VAE's final upsample stage, and it gets louder the moment you sharpen or upscale the result. That explains the pattern people notice, where the image looked clean in the preview and looked dirty after a finishing pass.

So the fix belongs at the decoder, not at the sampler. She swaps in a texture-fixing VAE as the root correction, keeps DeGrid as a second-pass insurance policy, and explicitly does not treat the sigma schedule as the grid fix. When the export needs transparency, the DeGrid and color-correction steps come off, because they interfere with alpha.

The general lesson: a decoder artifact cannot be removed by resampling. If the pattern appears after upscaling, and it follows the tile structure rather than the subject, you are looking at the VAE, and no amount of step tuning will touch it.

Layer three: geometry

The third failure is the one that ruins otherwise acceptable work. After an instruction edit, the result drifts against the reference: the waist sits a few dozen pixels lower, the head is rotated slightly, the whole frame is warped by a degree or two. On its own each shift is invisible. Put the edit back into a sequence, a mockup, or a print layout and it becomes a visible jump.

Her fix is Qalign, and the interesting part is what it is not. It is not another diffusion pass. It is classical computer vision: ORB feature detection, RANSAC to reject outliers, ECC refinement to solve the alignment. No model, no resynthesis, no new pixels invented to bridge the gap.

That choice is correct for a reason worth naming. The transformation between a reference and an edit of the same scene is close to rigid or affine, and a transformation of that kind can be estimated from matched points and then reversed. Estimated, not measured exactly, and reversed approximately: feature matching produces an estimate, an affine model ignores perspective and local deformation, and an optical-flow refinement can smear fine detail if it is switched on. That is why the verification step below matters more than the alignment setting.

Her operating rule is equally clean. Local edit that must not move anything: alignment on. Edit that deliberately changes composition: alignment off, because forcing the geometry back would fight the intent.

The alternative, a diffusion pass asked to "fix" the alignment, would re-imagine the region to make it fit. That repeats the mistake of regenerating to fix lighting: you get a plausible image and lose the approved face.

The part I would add

Order of operations matters as much as the three fixes, and this is where a pipeline usually breaks. Align last, then verify, then stop. If you run Qalign and then push the frame through another sharpening, upscale, or export step that resamples it, you have reintroduced sub-pixel drift and you will spend the afternoon chasing it.

For verification, stop trusting the preview at fit-to-window. Three checks, all cheap:

Put the result over the reference as a difference blend at 100 percent. Drift shows up as an edge halo on the subject, and grid noise shows up as a regular pattern in the flats. They look nothing alike once you are looking for both.

Flick between the reference and the result at full zoom, on the eyes and on the garment seams. Rigid offsets that are invisible side by side are obvious in a flicker.

Measure the offset numerically before you accept the alignment, not after. A two-pixel error at 1K is a six-pixel error at 3K, and the second one is visible in a print.

What transfers

Strip the model names and the structure that remains is a triage list. When a fast local pipeline disappoints, ask which layer failed: how long it took to compute, what the decoder produced, or where the pixels ended up. Each has a different owner and a different fix, and only the first one is about steps.

That is also why "it looks slow" and "it looks bad" are such poor bug reports in a diffusion graph. They describe a symptom that three unrelated layers can produce, and the fix that helps one of them will quietly make the others harder to see.

If you want the earlier half of her Qwen Image 2.1 analysis, including why a low-step community template makes the model look worse than it is, that is covered in Qwen Image 2.1 is an edit bench, not a first-frame generator. And the general version of the geometry problem, where repeated edits walk a subject away from itself, is in why repeated AI edits silently change the subject.