Repository navigation
Make local image generation reliable, including runtime setup and recovery #319
Description
Image generation should work on its own, without needing the llama.cpp chat server to be running. I checked how the request moves from the chat screen through the model catalog and the local stable-diffusion.cpp renderer, and found several places where a missing runtime, unsupported model or failed render could leave the user stuck.
The direct image request path has since been fixed in #320. Image prompts no longer have to pass through a text model first, English, Bangla and Russian image commands are handled more reliably, and unsupported FLUX generation is no longer presented as available. PR #321 improved runtime ZIP extraction and prevented competing installs within the app. PR #322 fixed the way generated files are opened and revealed on Windows, Linux and macOS.
There are still a few things I want to see working properly before treating local image generation as reliable:
- A way to install, check and repair the diffusion runtime in Settings, with useful download progress and error messages.
- Clear handling when a GPU runtime is missing or fails to start. CPU fallback should be explicit, since it can be considerably slower.
- A job queue that shows rendering progress, supports cancellation and recovers cleanly after timeouts or crashes. Failed jobs must not appear as completed images.
- Image options people actually need, including resolution, aspect ratio, seed, steps, negative prompts and the ability to generate again.
- A working FLUX renderer before offering FLUX as an available generation choice.
- Stronger checks on output files, so corrupt images cannot be saved as successful results. That work is being reviewed in Validate rendered PNG integrity before publishing image artifacts #348.
I also want a real SDXL rendering test on supported hardware, not just passing CI. The test should cover starting with no runtime installed, downloading the necessary files, producing a usable PNG, opening it, retrying a failed request and recovering after an interrupted run. Windows, Linux and macOS need separate verification wherever their runtimes differ.
The earlier code review was done against commit 17d78bf. Automated tests do not prove that image inference actually succeeded on a GPU. I have not recorded a complete physical device rendering test for this issue.
Activity
smshagor-dev commentedon Oct 19, 2026
I started on the direct image-generation problem in #320. The change sends SDXL requests to the local renderer instead of relying on llama.cpp chat inference first. It also improves English, Bangla and Russian prompt detection, prevents an FLUX-only model from being treated as an SDXL renderer, and makes browser previews report honestly when no desktop rendering occurred. The remaining work is around runtime installation, GPU fallback, cancellation and testing an actual generated image on supported hardware.
smshagor-dev commentedon Oct 19, 2026
PR #320 has been merged. Image requests can now reach the local renderer without a running text-model server. I also opened #321 to make diffusion runtime downloads and archive extraction safer, and #322 to fix how generated files open on Windows, macOS and Linux. These changes deal with some of the failures found in the audit, but they do not yet make the whole image-generation experience complete.
smshagor-dev commentedon Oct 19, 2026
PRs #321 and #322 have now been merged into main, with their CI checks passing. The runtime installer is better protected against unsafe archives and simultaneous installation attempts, and generated files use the correct system commands to open or reveal them. I'm also working on #348 because the old image validation only checked the PNG signature and size; that could let a broken image appear as a completed artifact. Runtime setup from Settings, proper progress and cancellation, model fallback, FLUX support and an actual SDXL rendering test still need attention.
[-]Image generation: production readiness, independent rendering and runtime recovery[/-][+]Make local image generation reliable, including runtime setup and recovery[/+]smshagor-dev commentedon Oct 19, 2026
I reopened this issue because the image generator still needs work before it can be considered reliable. The earlier routing, runtime archive safety and cross-platform file-opening fixes have been merged. PR #348 is now checking the integrity of generated PNG files, and PR #359 adds a way to check, install and repair the separate diffusion renderer from Settings, with download progress. Both are waiting for their platform checks. I still need to validate a real SDXL render on supported hardware, and cancellation and device fallback have not been completed.
smshagor-dev commentedon Oct 19, 2026
The PNG validation change (#348) and the Settings image-renderer installer (#359) have both been merged. I’ve opened #383 for a separate CPU retry when an image fails. It adds a clearly labelled “Retry on CPU (slower)” action, keeps the normal GPU path unchanged, and only selects the CPU runtime after the user chooses it. The platform tests are running now. I still need to check a real SDXL render on hardware, and cancellation and rendering progress remain unfinished.
smshagor-dev commentedon Oct 19, 2026
PR #383 is merged now that the platform checks passed. You can retry a failed image on the slower CPU renderer without changing the normal GPU path. I’ve started #404 to let people stop an individual image render from its card. It tracks each running image independently, stops the selected render, removes incomplete output and saves a cancellation message rather than marking the image ready. Frontend checks have passed; the remaining CI checks and a real hardware cancellation test are still pending. Generation progress and recovery of interrupted jobs need more work.
smshagor-dev commentedon Oct 19, 2026
PR #404 has been merged after its cross-platform checks passed. Images now have their own Stop button, with cancellation tracking that does not affect chat inference. I opened #421 for images left in a
Generating…state after an interruption. It marks image jobs older than four hours as failed and retryable, and cleans up incomplete files through the existing path-restricted cleanup function. The age limit protects recent jobs that may still belong to another running app instance. The check runs for #421 are still underway; rendering progress and physical hardware tests remain to be done.smshagor-dev commentedon Oct 19, 2026
PR #421 is merged after the platform checks passed. Old image artifacts left in
Generating…now become retryable when they exceed the four-hour safety window, including when a chat or the Library is reopened. I’ve opened #432 to show what a running image is actually doing: preparing its renderer, rendering, and validating the PNG, together with elapsed time. I am not showing a made-up progress percentage because the current renderer integration does not expose trustworthy per-step completion data. CI for #432 is running; real device inference and more detailed rendering progress still need testing.smshagor-dev commentedon Oct 19, 2026
PR #432 has been merged after all of its checks passed. Image cards now show preparation, rendering and output-validation stages with elapsed time. I’ve opened #434 to read the SDXL renderer’s progress output while it runs and show actual sampling step counts when the log format supports them. The same change limits captured renderer logs to avoid memory growth during a long generation. The new PR is still under CI review. A real SDXL image-rendering test on supported GPU/CPU hardware, model-specific controls and immediate crash recovery still need attention.
smshagor-dev commentedon Oct 20, 2026
The live SDXL sampling-progress update (#434) has been merged after passing its checks. I’ve opened #436 to prevent simultaneous image render processes from competing for GPU memory. New images will wait for the current render to finish, and a waiting image can still be stopped independently. The queue and cancellation tests are included, and the new PR is undergoing Windows, Linux, macOS and frontend validation. Real SDXL rendering on physical hardware and coordination between separate app processes remain unverified.
smshagor-dev commentedon Oct 20, 2026
PR #436 is merged now that all cross-platform checks passed. The image render queue is in
main. I found another issue while checking how that queue works with interrupted-job recovery: a legitimate long-running render or queue wait could become older than the four-hour cutoff and be marked failed. PR #439 now renews the timestamp of active images every minute, without touching completed files, and includes database recovery regression tests. The new CI checks are running. Physical SDXL rendering and multiple-app-instance behavior still need validation.smshagor-dev commentedon Oct 20, 2026
The image heartbeat fix (#439) has been merged after every check passed. I’ve opened #443 for image-generation controls: the chat composer now has an optional seed, negative prompt and sampling-step input, forwarded through the desktop API to the pinned SDXL CLI with input validation. Leaving seed and steps blank preserves the existing defaults. The PR is under CI review. Resolution, aspect ratio, saving render settings per artifact for exact retries, and a physical SDXL render on supported hardware still need separate work.