Dream Pixel Forge: Local GUI to Agentic Studio

Updated July 2026. The Dream Pixel Forge name now belongs to a web product. The original local GUI this post was written about is still open source, and its history is preserved below.

Dream Pixel Forge is now an agentic AI image and video generator. You state intent and agents do the prompting: a creative director agent plans the set, writes the prompts, generates, and reviews the output against the brief, regenerating anything that fails. Give it your website URL and it reads the page to learn your brand colors and style, so what comes out looks like it belongs to you.

It runs in the browser at dreampixelforge.com, with purpose-built jobs underneath (product and lifestyle scenes, virtual staging, YouTube thumbnails, ad variations, logos, stickers) and an MCP server plus a dpf CLI so Claude can generate images without you leaving your agent. Try-it widgets need no account, and signing up gives you 15 credits with no card. I demoed the whole thing at Seattle Tech Week if you want to watch it run.

It began life as something very different: an open-source desktop app for running Stable Diffusion locally on your own GPU. That original tool is still on GitHub as a legacy project, and the rest of this post is the engineering write-up of how it worked. If you came here looking for the local GUI, keep reading. If you want to make an image right now, the web app is the place to go.

Why I moved it to the web

Local GPU setup is a wall that keeps most people out. The desktop app assumed you had a machine with enough VRAM, a working CUDA or Metal stack, and the patience to download multi-gigabyte model weights before you saw a single image. That is fine for hobbyists who like the toolchain. It is a non-starter for someone who just needs a thumbnail before they publish a video.

If you are building against hosted image APIs instead, my AI model API ID reference lists the current GPT Image, Nano Banana, and Grok Imagine slugs.

A hosted product removes all of that. It can run frontier models on hardware the average user will never own, apply quality checking to outputs instead of handing you whatever the sampler produced, and serve people who want the image, not the pipeline. The generators are also opinionated on purpose: a YouTube thumbnail preset composes for small-screen readability, a virtual staging preset expects an empty room. That kind of job-specific tuning is hard to justify in a general-purpose local GUI and easy to ship when you control the backend.

Where it started: the local GUI (2025)

DreamPixel Forge started as a desktop GUI for running Stable Diffusion models locally. It supported SD 1.5, 2.1, XL, Dreamlike Diffusion, Kandinsky 2.2, Pony Diffusion V6 XL, and custom CivitAI models, all managed from a single interface with built-in LLM prompt enhancement via Ollama. Everything below is how that version was built.

Why build another Stable Diffusion frontend?

ComfyUI was powerful but node-based. Great for complex workflows, bad for someone who just wanted to type a prompt and get an image.

Automatic1111 covered the basics but felt bolted together, and switching between model architectures (say, SD 1.5 to Kandinsky) usually meant different UIs or manual configuration.

I wanted something simpler: one app where you pick a model from a dropdown, type a prompt, and hit generate. No nodes, no YAML files, no hunting for the right command-line flags. And I wanted the whole thing to stay local: no cloud API keys, no data leaving your machine.

Choosing Tkinter (yes, really)

I went with Tkinter for the GUI. The obvious question is why not Electron or a web-based frontend, and the answer was dependency weight.

DreamPixel Forge already pulled in PyTorch, diffusers, transformers, and model weights that could be multiple gigabytes. Adding Electron on top of that felt wrong. Tkinter ships with Python, zero extra dependencies, and it ran on Windows, macOS, and Linux without any platform-specific packaging for the UI layer.

The trade-off was obvious: Tkinter looks dated, and advanced layouts are painful. But for a form-based app (text fields, dropdowns, buttons, image preview), it did the job. The time I didn't spend fighting Electron went into features that actually mattered.

Dealing with VRAM across models

The hardest part of supporting multiple model architectures in one app was VRAM. SD 1.5 ran comfortably on 4GB, SDXL wanted 8GB+, and Kandinsky sat somewhere in between.

If you loaded an SDXL model on a 4GB card with the same settings you'd use for SD 1.5, you got an out-of-memory crash with no useful error message.

DreamPixel Forge handled this with per-model configuration: each model got its own resolution presets, default negative prompts, and VRAM warnings. When you switched models, the UI updated to show sensible defaults for that architecture. If you imported a custom model from CivitAI, the app inspected the file to detect whether it was SD 1.5, SD 2.1, or SDXL and applied the right configuration automatically.

For GPU acceleration, it was CUDA on Windows and Linux, Metal Performance Shaders on Apple Silicon. The app detected the available backend at startup and configured PyTorch accordingly. On machines with no supported GPU, it fell back to CPU. Slow, but it worked.

The Ollama prompt enhancement pipeline

This was the feature I was most satisfied with. Most people don't write good image generation prompts. They type something like “a cat in space” and get mediocre results, then assume the model is bad.

DreamPixel Forge connected to a locally running Ollama instance and used whatever LLM you had installed to rewrite prompts. It worked in two modes: tag conversion (turning a natural language sentence into comma-separated tags optimized for the selected model) and creative expansion (telling the LLM to build on your idea and add detail). The app queried Ollama's API to list available models, so you picked which LLM to use from a dropdown, no configuration files.

The key decision was keeping this entirely local. Cloud-based prompt enhancement would have been simpler to implement, but it defeated the purpose of a privacy-focused local tool. Ollama made this painless: if it was running, the feature was available; if not, the UI simply hid the enhancement options. That instinct is exactly the one the web product inverts: hosting the models is what makes job-specific quality possible.

App icon generation

This started as a personal itch. I kept generating icons for side projects and then manually resizing them in an image editor, applying corner radii, and exporting at every required size for iOS and Android. So I built it into the app.

The icon preset configured square output (512x512 or 1024x1024 depending on model), 25 inference steps, guidance scale 7.0, a batch size of 4 for options, and a negative prompt tuned to avoid text artifacts. After generation, a post-processing step applied corner radii with proper transparency, generated all platform-required sizes, and named files according to iOS/Android conventions.

What I'd do differently

If I were starting the desktop app over, I'd split the model management into a separate background service instead of handling downloads and loading in the GUI thread.

The prompt enhancement pipeline worked surprisingly well: it was the single feature that most improved output quality for casual users. But downloading a multi-gigabyte model blocked the UI in ways that Tkinter's threading model made awkward to fix cleanly. In hindsight, the friction I kept running into with local setup was the signal that the whole thing wanted to live on the web.

The original GUI is still open source on GitHub (legacy), with installation and setup details in the README. For the current product, head to Dream Pixel Forge on the web. If you'd rather generate images from inside an AI agent, I also built an Image Generation MCP server, and VibeCoder takes the same local-first approach for writing code.