In development Personal product 2026–present

Local Image Studio

A personal creative-production system for developing linocut-oriented image studies on one local workstation. My work is the orchestration and product layer around open-source generation and training tools: queueing, recovery, resource decisions, print preparation and a browser interface.

  • Python
  • SQLite
  • PyTorch
  • CUDA
  • ComfyUI
  • Pillow
  • Vanilla JavaScript
  • Local model tooling
Concept illustration — no private project data shown.

01 · Problem

What needed solving

Local image-generation tools are powerful but fragmented. Long jobs, incompatible environments, limited GPU memory and the path from an experiment to a printable asset all need coordination.

Create a dependable studio workflow that treats generation as a sequence of reviewable jobs rather than a collection of fragile command-line sessions.

02 · Constraints

The difficult parts

  • Coordinate generation and training tools that require separate Python environments.
  • Recover completed or interrupted work after process failures without duplicating expensive jobs.
  • Respond to GPU memory pressure without silently reducing output resolution.
  • Preserve enough metadata to reproduce a print study while keeping private prompts and training material private.

03 · Approach

How the work was structured

  1. Built a persistent SQLite queue and an orchestration layer of roughly 5,800 lines around third-party engines and trainers.
  2. Adopted completed engine tasks after restarts and retried memory failures by reducing batch size rather than image dimensions.
  3. Isolated tool environments and recorded each output with sidecar metadata.
  4. Added super-resolution and linocut-oriented preparation steps behind a lightweight browser interface.
  5. Measured cached, uncached, quantised and full-precision paths before choosing resource defaults.

04 · Validation

What can be claimed now

An end-to-end local generation workflow is working. Resource choices were benchmarked on the target GPU, and the queue has explicit recovery behaviour for completed and failed engine tasks.

The studio can take work from queued generation through review and print preparation on one machine. It remains in development while model-management and fine-tuning flows are refined.

05 · Learning

What the project clarified

  • Resource constraints are product constraints and should be measured explicitly.
  • Persistent jobs and recovery paths matter more than a polished interface when each task is expensive.
  • The orchestration layer must clearly distinguish original product work from the open-source engines it coordinates.

Next

Planned follow-through

  • Strengthen dataset validation and permission records for fine-tuning inputs.
  • Improve comparison and approval tools for print studies.
  • Prepare a public demonstration using only non-identifiable, rights-cleared source material.