Image Generation Ecosystem
A model-first local creative stack spanning image generation, identity, dataset preparation, and video.
WebbDuck — model-first generation
Public verification: the WebbDuck, DNADuck, and DuckMotion repository links above expose implementation history, README documentation, and source.
WebbDuck is now a multi-backend local image studio rather than an SDXL-only frontend. SDXL, FLUX, Krea 2, and Qwen backends sit behind a checkpoint-driven generation contract with model descriptors, capability-aware controls, isolated runtimes, and queue-first GPU orchestration. Identity / Persona workflows span SDXL FaceID, native FLUX.2 multi-reference conditioning, and Krea Identity editing. DNADuck handles face identity clustering and LoRA dataset preparation, while DuckMotion extends the same workstation into Wan 2.2 image-to-video.
01. WebbDuck: the model is the routing key
The Studio workflow stays model-centric: choose a checkpoint and WebbDuck resolves the appropriate backend, runtime, capabilities, defaults, and constraints. The current backend map includes SDXL, FLUX, Krea 2, and Qwen. Higher layers work through normalized model descriptors and a generic generation contract rather than forcing users to choose an engine or spreading architecture checks across the UI.
02. Queue-first GPU orchestration and isolated runtimes
GPU-heavy generation runs through a central queue with WebSocket progress, cancellation, lease coordination, and persistent output metadata. Newer backends can run in isolated Python environments so model-specific Diffusers, Transformers, quantization, or CUDA dependencies do not destabilize the known-good stack. Runtime readiness and routing are resolved before work is dispatched, and all four backends share the same top-level job lifecycle.
03. Identity / Persona across architectures
A saved Persona is a product concept, not one backend feature. SDXL uses IP-Adapter FaceID, FLUX.2 uses native multi-reference identity conditioning with ordered references, and Krea 2 uses a single-anchor identity-edit path with its own LoRA and grounding controls. The UI is capability-driven so model-specific identity settings appear only where they are meaningful while the user keeps one consistent Persona workflow.
04. Krea 2 identity: quality and performance engineering
The Krea identity path required more than simply loading another pipeline. The implementation includes identity-specific geometry, LoRA conversion, adaptive token planning, block streaming/residency strategies, OOM demotion, reference preprocessing, and server-side upscale-back to the requested dimensions. Hardware A/B work drove defaults and exposed the real bottlenecks instead of hiding them behind generic “low VRAM mode” switches.
05. Editing, gallery, and asset history still matter
WebbDuck keeps the practical workstation features that made the original SDXL version useful: img2img, inpaint, outpaint/smart extend, two-pass refinement where supported, upscaling, LoRA and embedding discovery, searchable filesystem-backed history, metadata sidecars, thumbnails, lightbox actions, and live catalog refresh. Capabilities now decide which controls are valid for the selected model.
06. DNADuck: identity pipeline for dataset preparation
DNADuck recursively scans image libraries, detects and embeds faces with InsightFace, clusters identities with DBSCAN, and stores durable state in SQLite. Review, merge, search, and export workflows turn messy collections into repeatable LoRA-ready datasets while preserving source files. CLI, API, and WebbDuck plugin surfaces all operate on the same underlying identity state.
07. DuckMotion: local image-to-video in the same workstation
DuckMotion adds Wan 2.2 image-to-video through a WebbDuck plugin surface. It handles staged uploads, model discovery, runtime compatibility, queued generation, cancellation, shared GPU constraints, and a plugin-local gallery so video generation behaves like part of the workstation rather than a disconnected script.
08. Design principle: architecture-specific internals, architecture-neutral product
SDXL, FLUX, Krea 2, and Qwen are allowed to have very different runtimes internally. The product contract stays stable: select a model, expose only supported controls, route through the right backend, produce normalized results, and preserve the artifact in the same local history. That lets the stack grow without turning the main UI into an engine-selection control panel.
A local creative workstation that has grown from an SDXL app into a model-first multi-backend platform with cross-architecture identity workflows, isolated runtimes, durable gallery/history, dataset preparation, and image-to-video plugins — while keeping the user experience centered on models and creative tasks rather than backend architecture.