Coloring Stack — Batch coloring pages from a prompt

The idea

Coloring pages on specific themes (a dragon with an astronaut helmet, a favourite animal with a crown, a Pokémon in a kitchen) are popular in families and schools — but usually only generic stock art is available. Existing AI tools are usually cloud-bound, expensive per image, and hard to steer to the line-art format that a printable coloring page actually needs.

Coloring Stack is a desktop tool that solves this pipeline locally. It also works as a Stackschmiede showcase for “what a well-designed on-prem AI application looks like” — thought through from backend to frontend.

Architecture

Two processes, one application. The Python backend runs as a FastAPI service on 127.0.0.1:<random>. The WinUI 3 frontend launches it and talks over HTTP + Server-Sent Events.

┌─────────────────┐   HTTP/SSE   ┌───────────────────┐
│  WinUI 3 (C#)   │◄────────────►│  FastAPI (Python) │
│  ColoringStack  │              │  coloring-stack-  │
│       .App      │    stdout    │  backend.exe      │
│                 │  BACKEND_    │                   │
│  ProcessMgr ────┼──READY───────┤  SDXL + LoRA      │
│  BackendClient  │              │  + Real-ESRGAN    │
│  SseClient      │   Bearer     │  + Job registry   │
└─────────────────┘    token     └───────────────────┘

Handshake: the backend binds port 0 (OS picks a free port), then prints BACKEND_READY port=N token=T on stdout. The frontend parses this, remembers port + token, all further calls go through bearer auth. That keeps other local processes out without OAuth overhead.

SSE streams for live progress (job phase, current image, ETA, GPU temp, VRAM). Cancel via threading.Event → SDXL pipe._interrupt = True (stops after 1–2 steps). The frontend ProcessManager is the ultimate watchdog on a stall.

Tech stack

Backend (done, phases 1–6):

• Python 3.12 + FastAPI + Uvicorn
• Stable Diffusion XL with line-art LoRA
• Real-ESRGAN x4plus-anime-6B for upscaling
• Pydantic v2 for API schemas
• pytest with fake generator (tests run without CUDA)
• PyInstaller onedir bundle for shipping

Frontend (in progress, phases 7–15):

• WinUI 3 + .NET 8 (C#)
• Windows App SDK + CommunityToolkit.Mvvm
• Brand-consistent theming: solid charcoal, amber CTAs, Inter + JetBrains Mono embedded
• Custom controls: PrimaryButton with sheen, GpuGauge, ColoredProgressRing, ThumbCard

Shipping (open, phase 16):

• Inno Setup bundles backend onedir + frontend unpackaged
• HF models are pulled on first run into %LOCALAPPDATA%\ColoringStack\models (not in the installer, ~7 GB)

Design decisions

Mica explicitly off. WinUI 3 defaults to a semi-transparent Mica backdrop. That looks different on every desktop (depending on wallpaper) and reduces the readability of line-art thumbs. Coloring Stack uses solid #0F0F10 (brand token InkDeep) instead. The reasoning is in the repo.

Custom title bar. Stackschmiede hexagon logo on the left instead of the white Fluent title bar. ExtendsContentIntoTitleBar = true.

Status honesty. The app always says what it’s doing — GPU temp, VRAM, current phase, ETA. Silence = bug.

Status today (April 2026)

• Backend: complete (phases 1–6 ✓). FastAPI service, tests, build pipeline done.
• Rebranding: repo renamed to stack-coloring, GitHub remote updated, project names in code refreshed.
• WinUI design concept: 4 markdown documents + visual HTML reference. Drives the implementation.
• WinUI implementation: not started yet (phases 7–15) — needs a Windows machine with VS 2022 + Windows App SDK.
• Installer + E2E: phases 16/17 open.

Screenshots will follow once the WinUI phase is running.

What this project shows

• AI integration without an API wrapper — the full pipeline (model loading, inference, postprocess, QA, batch orchestration) is hand-built.
• Desktop app with a service architecture — instead of a monolithic PySide6 bundle: backend service + native Windows frontend with a clear IPC contract.
• Design-first workflow — spec before code. The UI/UX concept exists before the first .xaml file.
• Realistic solo scope — doable with AI assist, even at this project size.

Why interesting for you?

Because the same architecture — backend service + native frontend + brand-consistent delivery — transfers to other domains:

• Document pipelines: invoices, contracts, briefs processed locally instead of uploaded to OpenAI
• Internal RAG bots: domain corpus on your own hardware, desktop client for the team
• Batch analysis tools: scientific data, image archives, log files — local, reproducible, no cloud dependency

See the service package Sovereign AI Integration too.