stablediffusionapi/anything-v5 reorganized into diffusers folder format,
so the single-file checkpoint URL now 404s. Switch to Yntec/AnythingV5
which still hosts Anything-v5.0-PRT.safetensors as a single file.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Wan2GP renames its Gradio api_names between releases (and Pinokio packages
drop them on some endpoints), so our hardcoded fn strings (ltx_video, flux,
qwen_image, wan22_t2v, etc.) failed against any current server with
"Could not infer function index for API name". Now we pull /info at probe
time, cache the registered api_names per base URL, and remap each catalog
entry via exact fn match → fnAliases → fuzzy family+type match. Unmatched
models report a clear unavailableReason in listModels(), and generate()
throws an error listing the real available endpoints instead of a cryptic
Gradio traceback.
Fixes#135.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Closes the gap reported in #126 where local users hit "Not authorized:
missing or invalid credentials" on upload and couldn't generate video
locally even with WanGP installed. Image, video, and reference uploads
were all hard-wired to the Muapi-hosted upload endpoint, and Video
Studio had no branch into the local Wan2GP provider for generate.
- electron/wan2gpProvider: new wan2gp:upload-file IPC that POSTs to the
Gradio /upload endpoint, caches the returned path, and rehydrates it
into a Gradio FileData descriptor on generate. Adds wan2gp:wan22-i2v.
- preload + localInferenceClient: expose uploadFileToWan2gp(file).
- localModels: wan22-i2v entry, isWan2gpModelId, localT2VModels/localI2VModels.
- UploadPicker: accept optional uploadFn + requireApiKey so callers can
bypass the Muapi auth modal when the active provider is local.
- VideoStudio: merge Wan2GP video models into t2v/i2v lists, route the
reference-image upload through the local provider when a Wan2GP model
is selected, skip the Muapi key gate for local generations, call
localAI.generate, and surface step progress in the button label.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The catalog pointed at huggingface.co/Lykon/dreamshaper-8 which now returns
404 — the live HF repo is huggingface.co/Lykon/DreamShaper. Confirmed by
probing both URLs and downloading the file from the corrected one.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The desktop app already has a bundled sd.cpp engine for local generation. This
adds a second, complementary engine: an HTTP client that talks to a user-run
Wan2GP Gradio server (https://github.com/deepbeepmeep/Wan2GP). Useful when
sd.cpp can't run a target model — Wan2GP brings video models (Wan 2.2,
Hunyuan, LTX) and large image models (Flux, Qwen-Image) without bundling
Python or weights into the app.
Architecture
- Each model in the unified catalog now carries a `provider` field
(`'sdcpp' | 'wan2gp'`). The renderer's `localAI.generate()` routes to the
right backend based on that flag.
- sd.cpp keeps its existing IPC channels (`local-ai:*`) untouched. Wan2GP
gets its own channel namespace (`wan2gp:*`) and lives in its own
`electron/lib/wan2gpProvider.js`.
- Wan2GP server URL is persisted in `userData/local-ai/wan2gp.json`.
`Settings → Local Models` exposes a config bar to test/save the URL.
- Generation streams Gradio v4 SSE protocol; both engines emit progress on
the shared `local-ai:progress` channel.
ImageStudio
- Local-model dropdown now filters out video models (`type === 'video'`)
since the studio is image-only. SD 1.5 / SDXL / Z-Image (sd.cpp) and Flux /
Qwen-Image (Wan2GP) still surface; Wan/Hunyuan/LTX are hidden until the
Video Studio is wired up to the same surface.
- Progress event handler updated to tolerate both engines' shapes.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Fixes#108 — leejet's latest sd.cpp release (master-587-b8bdffc) only
ships Mac arm64, the Windows cudart runtime stub, and Linux ROCm. The
old matcher only ever read `releases/latest` and excluded ROCm/Vulkan,
so Ubuntu/Linux users hit "No binary found for this platform" with no
recovery path. Windows users were also broken: the only Win asset in
the latest release isn't an sd-cli build.
- Walk the last 15 leejet releases until one ships a usable build for
the current platform, so a partial latest release self-heals to the
prior tag (master-586 onwards has the full 12-zip matrix).
- Linux: prefer plain x86_64, then vulkan, then rocm (instead of
rejecting both rocm and vulkan).
- Windows: priority order avx2 > avx > avx512 > noavx > cuda12, and
skip the standalone `cudart-sd-bin-win-cu12-x64.zip` runtime stub.
- macOS Intel: surface a clear error — leejet only ships arm64.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
macOS Apple Silicon (darwin-arm64) now downloads the Metal-accelerated
sd-cli from our own GitHub release instead of the stock leejet build,
enabling significantly faster local image generation on M1/M2/M3/M4.
All other platforms continue to use the leejet upstream release.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Add electron:build:linux script and AppImage + .deb targets in package.json
- Fix Electron main.js: ESM → CommonJS, remove macOS-only titleBarStyle on Linux
- Fix createInlineInstructions undefined error in ImageStudio.js
- Fix Cinema Studio asset paths (absolute → relative) for Electron file:// protocol
- Add AppArmor profile for Ubuntu 24.04+ user namespace sandbox fix
- Add Ubuntu install docs and sandbox workaround to README
Update all references across source files, config, and docs — including
page titles, app name, package name, Electron window title, and release
asset URLs.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Add electron/main.js as the Electron main process
- Configure electron-builder for macOS (x64 + arm64 DMG) and Windows (x64 + arm64 NSIS installer)
- Add build scripts: electron:build (mac), electron:build:win (windows)
- Set vite base to './' for file:// protocol compatibility in Electron
