The problem

Generating a pretty image is easy. Getting the same character — same face, same costume, same ornament language — out of a diffusion model in a completely new scene is the hard part, and it is what production actually needs.

The root cause is a trade-off I mapped through repeated experiments: text-to-image gives you full freedom of pose and staging, but the costume design drifts on every roll; image-to-image anchored on the character sheet preserves the design almost pixel-perfectly, but locks the pose. A production pipeline has to navigate between those two poles deliberately — not hope for a lucky seed.

The pipeline

1. Character sheet first. A full-body concept locks the design: silhouette, materials, palette, face. (Hand-directed generation with a self-trained style LoRA, plus paintover.)
2. Identity-preserving staging. The splash is built from the sheet — image-to-image with the sheet encoded as the latent anchor, composition and lighting rewritten in the prompt. The critical dial is denoise: around 0.5–0.65 the detailed character survives while the empty backdrop re-renders into the new scene. Below that nothing changes; above it the costume starts to dissolve.
3. Element grafting. New scene elements (props, effects, crowds) are painted in as rough proxies, then re-rendered in place so they inherit the style — the model treats the proxy as composition guidance and redraws it in the trained look.
4. Face & finish. Expression control via face-detail passes at low denoise (0.2–0.35, so the face refines without changing identity); final paintover and a tiled 2× upscale for delivery.

The actual graph

The image-to-image staging graph exactly as it runs — an open-weights base model with a self-trained style LoRA stacked on top, the character sheet loaded and VAE-encoded as the latent anchor, a positive-only prompt (at CFG 1 the negative is zeroed out), and the identity-preserving denoise on the sampler:

Reading the graph left to right: model + LoRA stack, the prompt block, the character sheet entering as the latent — all meeting in one sampler whose denoise value decides how much of the sheet survives. Every splash post on this site went through a variant of this graph.

Worked example

See Empress of the Lotus Pond — the standing sheet and the pond splash are the same character to the pixel level of the costume. The same pipeline produced the Golden Emperor key visual and the Dark Legion action variations.

What validation taught me

• Prompt structure matters more than prompt length. At CFG 1 everything is positive conditioning — banned elements must be removed from the vocabulary, not negated.
• The backdrop is part of the style contract. The style LoRAs were trained on dark cinematic backdrops; staging against a flat studio background suppresses the learned look.
• Fix identity first, then compose. Rolling composition variants before the design is locked multiplies drift; locking the sheet first turns splash production into a controlled, repeatable step instead of a lottery.

One image in — that is the whole workflow

You give the graph exactly one image: a side view of the weapon. That is the entire input. One queue later you have the side profile, 3/4 front and rear, the opposite side, an optic close-up, the aim-down-sights shot — and the assembled product sheet. Same gun, same materials, same markings, across every camera, with no per-view prompting and no cleanup between angles.

One dial

Rotation is powered by a dedicated identity-preserving edit node: it anchors the weapon’s design while the camera moves — this is what makes true multi-view rotation possible at all. On top of it, a single reference-strength dial selects the operation:

Per-part colour blocking keeps an entire skin set consistent through every rotation.

Per-view camera scripts

Every view carries its own script: its camera position, its perspective, and its own list of exactly the parts that camera sees. The aim-down-sights view describes the stock and a mirror-symmetric frame; the product views describe the full silhouette. Each view renders precisely what it should — nothing leaks between cameras.

The graph

One fan-out graph: drop in any weapon image and it is encoded once, branched into every view, and stitched into the sheet at the end. Each view chains from the geometrically closest source image, so identity carries in pixels, not just words.

Result

Nine skins × up to seven views, assembled into a 10-page deck — published as Gunmaker Test in the ART section. Everything ran locally with no style LoRA — and not a single paid node or API call.

One image in — that is the whole workflow

You give the pipeline exactly one front-facing character illustration. That is the entire input. One queue later you have the left profile, the back, the right profile, up to two further rotations, and a stitched contact sheet — same costume, same proportions, same palette, across every camera. No per-view prompting, no manual rotation, no cleanup between angles: the finished deck below was produced from the single image loaded in the top-left node.

The one-queue graph

Everything runs as a single fan-out graph on the same identity-preserving edit engine as the Gunmaker, ported from hardsurface to the human figure. The models load once and feed every branch. Each view renders, purges its VRAM, and saves — then the strip assembles itself at the end.

Two details make it production-grade rather than a demo:

• Chained rotation. Each camera turns from the geometrically closest finished view, never more than a quarter turn per step — the back view starts from the freshly rendered profile, not from the front. Smaller steps, fewer errors.
• Spare rotation ports. Three fixed views are sometimes not enough for a stubborn angle, so two extra rotation stages sit behind on/off switches. Off, they cost nothing — the graph skips them entirely. On, they continue the turn from the last finished view, up to five rotations from one source image.

The parts table

Views are not prompted freehand. Every component of the design — jacket, harness, prosthetic segments — lives in one table as color + position + size, tagged with which side of the body it sits on, which plane it faces, and what it covers. Each view’s sentences are assembled from that table by rule and wired into editable text nodes on the canvas, so a tweak never means rebuilding the graph.

That structure is what keeps a deliberately asymmetric design honest: left and right profiles are generated from different part lists, a garment that covers other parts automatically suppresses them in the views it covers, and small front-facing plates are dropped from angles where perspective would crush them anyway.

View geometry is a contract

A camera definition can quietly contradict itself — and when it does, the symptom looks like a missing part, not a wrong camera. So the pipeline treats view geometry as a checked contract: a left profile means the figure faces screen-left, and a rear view means left and right swap on screen. Instead of trusting automated symmetry metrics, each run ends with a per-view QA checklist for exactly these checks — the judgment stays with the artist.

Assembly is not concatenation

Views that come out of the same pipeline still differ: background tones drift, figure heights vary, and cast shadows cling to the feet. Final assembly extracts each figure with a learned matting model — Photoshop’s background removal, driven automatically over a local bridge — normalizes everyone to a common figure height on a shared baseline, and refuses to build if any two cells contain effectively the same image. Cutouts older than their source view are invalidated automatically, so a re-rendered view can never ship with a stale silhouette.

Guarded hand-off

Every finished batch registers itself into the studio archive with its full prompt — no manual bookkeeping. The hand-off is gated twice: filenames must be unique across the batch, and the archive row count is compared against the files on disk. Silent overwrites don’t pass.

Result

Two published works in the ART section came out of this pipeline: the Shooter Bunny Amethyst sheet — two outfit variants × four views on one deck, plus the weapon sheet from the Gunmaker — and the Triumphant Blade Dancer turnaround, the pipeline’s first full run. All local, zero paid calls.

Overview

A style LoRA reproducing a flat casual game-art look, trained and operated end-to-end: dataset curation, caption engineering, training, epoch-sweep validation, and pipeline integration. This card documents the full process — the same recipe drives every style model on this site.

Why a LoRA, briefly

A base diffusion model knows a thousand styles vaguely and none of them precisely. A LoRA (Low-Rank Adaptation) freezes the base model entirely and trains only small low-rank matrices injected alongside its attention weights — here rank 32, a few tens of megabytes against a multi-gigabyte base. Because the base stays frozen, the model keeps its anatomy, composition and prompt understanding; the LoRA only has room to learn what the dataset consistently shows that the base doesn’t already know. Curate the dataset so the only consistent signal is the style, and that is what it learns.

Dataset — the funnel

Built with my own dataset tool (see the Datacurator card): 1,167 candidate images reviewed → 521 kept after ML-assisted selection and manual review → 58 finally curated for training. The last cut is the strictest: near-duplicates, off-style outliers, multi-panel sheets and screenshots all get dropped, because with a small dataset every bad image is 2% of the signal.

Caption design got the same treatment as the data — engineered, tested and validated; the specifics stay in-house as part of the recipe.

Training

The actual loss curve from the run log — the flat-with-noise shape after the early drop is expected for style training on a small dataset; the signal you watch is that it stays flat instead of collapsing (memorization) or climbing (divergence):

Validation — the part most people skip

Loss numbers don’t tell you which checkpoint to ship. Every checkpoint is swept with an out-of-distribution probe: a fixed seed and a fixed prompt for a subject that is not in the training data. In-distribution probes flatter the model — memorization looks like quality. An OOD subject shows what you actually bought: whether the style generalizes, and at which epoch style adoption starts costing anatomy or costume logic.

Fixed seed, no-LoRA baseline through epoch 26. Style locks in around epoch 10 without breaking structure — later epochs push the graphic look harder but start bending anatomy, so epoch 10 ships as the standard operating point and later checkpoints are kept as deliberate stronger dials.

In production

Used in the Aristocrat Knight splash pipeline and the flat-track concept posts. Operating notes discovered in validation: the style expects clear silhouettes and reads best with restrained prompts — over-describing the render fights the LoRA instead of helping it.

Overview

A style LoRA for cinematic, low-saturation painterly realism — the workhorse behind the splash-pipeline posts (Empress of the Lotus Pond, Saint of the Storm, Golden Emperor).

Card

Notes

Prompting rules discovered in validation (front-loaded subject, positive-only phrasing at CFG 1, backdrop placement) are documented per post in the Process sections.

Sample output

Delivered splash art generated with this LoRA at its standard operating point:

Overview

A personal artist-study LoRA for ornate painterly fantasy characters. Trained as a style exercise; used for the Dark Legion set and the Valkyrie in Motion action study.

Card

Notes

The interesting finding: the light-touch epoch keeps base-model anatomy and composition while carrying the surface language — heavier epochs win on style but lose flexibility.

Epoch sweep — out-of-distribution probe

Fixed seed, fixed prompt (a subject not in the training set), swept across checkpoints. This is how the operating epoch gets chosen — by evidence, not vibes:

Problem it solves

Iterating on character art means hundreds of generations per concept, spread across seeds, prompt revisions, LoRA weights and epochs. Reviewing that in a file explorer destroys both speed and judgment: no context, no comparison, no record of why an image exists. Atelier turns the folder-diving chore into a review workflow.

What it is

A local web app (FastAPI + SQLite backend, live-updating frontend) that every generation driver reports into. To date it tracks 1,100+ batches / 4,100+ images across 8 projects, organized as project → character → batch.

Design decisions that matter

• Every batch is ingested with its full generation record — the complete prompt, seed, sampler settings and LoRA stack per image. Six weeks later I can answer “how exactly was this made?” for any image on this site. No orphan outputs.
• Live gallery. New batches appear in the open browser within seconds of generation finishing — no refresh, no re-navigation. Review happens during the run, not after.
• Styles as presets. A style bundles a base workflow, a LoRA stack with weights, prompt rules and suggested settings. Validated recipes (e.g. “standard = epoch 10 @ 1.0”) become one-click starting points instead of tribal knowledge.
• Comparison is a first-class view. Side-by-side compare across styles or checkpoints on the same prompt — this is where epoch-sweep decisions actually get made.
• Picks and provenance. One-click picks mark the shortlist; batches can be reassigned as characters get promoted from experiments to real projects. Deep links (?character=…&batch=…) make any review shareable with myself across sessions.
• Round-trips to the tools. Any image can reopen its exact ComfyUI graph in one click, and upscale/face-detail actions run straight from the lightbox.

Why it exists

The pipeline claim of this whole site — directed, repeatable generation — is only true if the operator can see, compare and trace everything. Atelier is what makes the discipline cheap enough to actually practice.

Problem it solves

Every style LoRA on this site started as a dataset problem, and dataset quality is the single highest-leverage variable in style training — a rank-32 LoRA on 58 images has no capacity to ignore bad data. Collecting references, de-duplicating, cropping, rejecting off-topic images, captioning and exporting in trainer format is a full pipeline’s worth of work, so I built it as one.

The pipeline

Crawl → ML-assisted selection → human review → caption → export.

1. Crawl. Keyword- and gallery-based collection from reference sources.
2. ML-assisted selection. Perceptual de-duplication, aesthetic/quality scoring, and CLIP-embedding similarity suppression so the kept set stays diverse instead of collapsing onto the artist’s ten most repeated compositions. Rule-based auto-rejects (multi-panel sheets, screenshots, group shots) run as a natural-language instruction filter through a vision-language model.
3. Human review queue. Everything the machine kept still passes a keep/reject pass — for the flat-casual set that meant 1,167 images reviewed → 521 kept → 58 promoted to the final training set.
4. Caption engines. Switchable back-ends: booru-style taggers for tag-based models, VLM prose captioning for natural-language models — with a caption viewer for manual QA, because caption hallucinations (weapons and wings that aren’t there) poison style training.
5. Export. One click produces the trainer-ready folder: images, captions, and the repeat structure the training config expects.

Thumbnails blurred: source artworks are used for analysis during training-data curation and are not redistributed.

Why it exists

“Train a LoRA” sounds like a GPU task; in practice it is 80% data discipline. Making the data path a repeatable pipeline is what lets a new style go from idea to validated model in a day or two — and what makes the resulting models consistent enough to put into a production pipeline.

Problem it solves

Open a shared PSD and half the text layers show the yellow missing-font warning. The usual fix is manual: read the font name, search the web, judge an unfamiliar site, download an archive, dig out the right file, install it — per font, per document, per artist. On a team that trades PSDs daily (and every time someone gets a new PC), that is a steady tax on production time. FontHelper turns the whole loop into one double-click.

How it works

Scan → diff → search chain → verify → install.

1. Scan. Talks to the running Photoshop over COM and reads every open document — including fonts buried inside smart objects, recursively (embedded and linked PSD/PSB, plus a dependency-free scanner for .ai/.pdf/.eps vector smart objects).
2. Diff. Parses the name tables of locally installed fonts and subtracts them — with an mtime/size cache that cuts the check from 0.23 s to 0.02 s on warm runs.
3. Search chain. Each missing font walks ten free-font sources in priority order, from license-safe foundries down to last-resort mirrors, with a web-search button as the final human fallback.
4. Verify. Downloads are opened and the font’s internal name is matched against the request — a lookalike with the wrong name is skipped instead of installed, and every failure surfaces its reason in the UI (login wall, empty archive, name mismatch).
5. Install. Into the user font folder with per-user registry entries — no admin rights, safe on locked-down office machines.

License-aware by design

The result list is deliberately not one big “install all” button:

• Safe sources get a one-click install.
• Unclear-license sources require an explicit risk-acknowledgement checkbox and link back to the origin page — the tool refuses to make that judgement for you.
• Adobe Fonts are detected but deliberately left alone — recent Photoshop auto-installs them from Creative Cloud, so the tool only points there instead of downloading anything.
• A separate “install all safe fonts” bulk action exists precisely so the safe path stays one click without blurring the line.

Screenshot reproduced with a synthetic demo file — no production documents.

Engineering notes

Built test-first: 166 tests, with every site parser locked to real HTML fixtures so the suite runs offline and a source redesign shows up as a red test instead of a silent field failure. Ships as a single 33 MB PyInstaller exe — no Python, no installer, SmartScreen guidance included — with a rotating log in %APPDATA% so a coworker’s bug report can travel as one file. Photoshop connection falls back across COM ProgID versions, so multi-version and beta installs still connect. Distribution runs through GitHub Releases.

Why it’s here

Same pattern as the rest of this lab: find a repeating production task, build the tool, prove it on real work, hand it to the team. FontHelper is the non-generative end of that spectrum — spec-first design docs, AI-assisted implementation at high velocity, and a deliverable a non-technical artist can run without reading anything but a two-line SmartScreen note.

Overview

A style LoRA for clean chibi game art — a study analyzing the shape language, proportions and rendering characteristics of commercial chibi game art, demonstrating controlled style reproduction. Used for the Chibi Party set and the Gala Diva splash.

Card

Sample results

Works produced at the LoRA’s operating points — the target game style reproduced across different characters and costumes: