Lincoln Stein
8486d47b7f
frontend tests / frontend-tests (push) Has been cancelled
python checks / python-checks (push) Has been cancelled
lfs checks / lfs-check (push) Has been cancelled
openapi checks / openapi-checks (push) Has been cancelled
python tests / py3.11: macos-default (push) Has been cancelled
python tests / py3.12: macos-default (push) Has been cancelled
python tests / py3.11: windows-cpu (push) Has been cancelled
python tests / py3.12: windows-cpu (push) Has been cancelled
python tests / py3.11: linux-cpu (push) Has been cancelled
build container image / cpu (push) Has been cancelled
build container image / cuda (push) Has been cancelled
build container image / rocm (push) Has been cancelled
docs / changes (push) Has been cancelled
frontend checks / frontend-checks (push) Has been cancelled
python tests / py3.12: linux-cpu (push) Has been cancelled
typegen checks / typegen-checks (push) Has been cancelled
uv lock checks / uv-lock-checks (push) Has been cancelled
docs / check-and-build (push) Has been cancelled
docs / deploy (push) Has been cancelled
* ci: add pins.json consistency check, bump ROCm index to 7.1 pins.json is consumed only by the Invoke Launcher (fetched at the release tag) to pick the torch wheel index for legacy installs. Nothing in-repo references it, so it silently drifted from pyproject.toml: its Linux ROCm index stayed at rocm6.3 after the torch-rocm index moved to rocm7.1, causing the launcher to install ROCm 6.3 wheels (#9328, launcher#131). - Add scripts/check_pins.py, which fails if any torchIndexUrl entry in pins.json differs from the matching [[tool.uv.index]] URL in pyproject.toml. - Run it from the uv-lock-checks workflow, triggered by changes to any of pyproject.toml, uv.lock, pins.json, or the check script. - Bump pins.json rocm index to rocm7.1 (matches #9337) so the check passes. - Bump the workflow's uv from 0.6.10 to 0.11.28: uv.lock is already lock format revision 3, which 0.6.x cannot parse. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix: cap torch below 2.12 on linux/windows torch 2.12.x+rocm7.1 breaks generation (#9328; 2.11 works, and 2.10 is what the rocm extra pins). The cap only matters for legacy (pre-6.14) launcher installs, which resolve the base range live against the pytorch wheel indexes instead of using uv.lock — with the range open to <3.0, AMD users could land on the broken 2.12.x. Lockfile-based installs are unaffected: uv.lock stays at 2.7.1 / 2.10.0+rocm7.1 (no locked versions changed, only the recorded specifier). Remove the cap once the 2.12 ROCm incompatibility is diagnosed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * ci(check_pins): validate an explicit required platform/backend matrix Addresses JPPhoto's review. The checker only iterated the entries that already existed in pins.json, so deleting torchIndexUrl.linux.rocm still exited 0 — recreating the exact silent-fallback failure the guardrail was meant to prevent (the launcher only passes --index when the entry exists, and its schema makes every backend key optional). - Validate pins.json against REQUIRED_BACKENDS, an explicit matrix of the platform/backend combinations the launcher can select and Invoke supports. Missing entries, missing platform sections, unknown platforms and unsupported backends are now all errors, alongside the existing URL check. - Split the logic into check_pins(), with main() taking a repo root, so the exit code is directly testable. - Add tests/test_check_pins.py: removes each required entry in turn and asserts a nonzero exit, plus stale-URL, unknown-platform and unsupported-backend cases. - pins.json: add the win32.cpu entry the matrix exposes as missing. Without it, a Windows "no dedicated GPU" legacy install gets no --index and pulls the CUDA-bundled PyPI torch wheel instead of the +cpu build. Linux already had this entry. - python-tests: trigger on scripts/** and pins.json so these tests actually run when the checker or the pins change. - Revert the uv 0.6.10 -> 0.11.28 bump in uv-lock-checks: 0.6.10 parses the revision-3 lock fine (verified), so the stated justification was wrong and the bump left this workflow out of step with python-tests. * fix(deps): drop the blanket torch <2.12 cap; scope the ROCm caveat to docs Addresses JPPhoto's second review. The cap was applied to the base `sys_platform != 'darwin'` requirement, so it landed in published package metadata for every Linux and Windows install — CUDA, CPU-only and Linux ARM64 included — despite #9328 only ever reporting a ROCm 7.1 failure. My original justification ("only affects legacy pre-6.14 launcher installs") was wrong in both directions: - It never protected legacy launcher installs. Those install an already-released version, resolving against that release's frozen PyPI metadata, not this pyproject. - It never protected bootstrap (6.14+) launcher installs either. Those pass `invokeai[cpu|cuda|rocm]`, and every one of those extras pins torch exactly, so the base range is never consulted. - What it did affect is manual installs, which per docs/start-here/manual use `--torch-backend=<x>` with no extra and therefore resolve the base range directly — on every platform, not just ROCm. There is no environment marker for "resolving against the rocm7.1 index", so the cap cannot be scoped in metadata. Constrain it where it can actually be targeted instead: the `rocm` extra already pins torch==2.10.0+rocm7.1, and the manual install docs now carry a ROCm-specific caution with the `"torch<2.12"` workaround for users following the `--torch-backend=rocm7.1` path. pyproject.toml returns to `torch>=2.7.0,<3.0`, so uv.lock is untouched by this PR again. * docs: point the ROCm torch-2.12 caveat at an open tracking issue #9328 was closed as completed once pins.json was corrected to the rocm7.1 index; the separate torch 2.12.x generation failure reported in that thread had no open tracking issue, so the caveat had no removal condition. Filed #9410 for it and link there instead. Also narrow the cross-platform claim: we have no torch 2.12 smoke tests on CUDA/CPU/Windows/ARM64/MPS, so say only that the workaround applies to the reported ROCm case rather than asserting other backends are unaffected. * ci(pins): validate pins.json's python pin against requires-python The launcher's zod schema declares `python: z.string()` (required) and passes pins.python to `uv venv --python` on both the bootstrap and legacy install paths, before anything is installed. Bumping project.requires-python without bumping pins.json therefore builds a venv the package metadata then rejects - and the check passed, because it only looked at torchIndexUrl. check_pins.py now also checks that pins.json's python satisfies project.requires-python. It stays stdlib-only (CI runs it with a bare python3), so the specifier handling is hand-rolled and deliberately narrow: ==, !=, >=, <=, > and < against dotted numeric versions, zero-padded so 3.12 == 3.12.0. Anything it cannot evaluate is reported rather than guessed at. Differentially tested against packaging over 1014 version/operator/bound combinations with no divergences. Hardening found while attacking the above: - check_python never raises. requires-python is optional in PEP 621 and can be mistyped as a bare TOML float; either used to throw out of check_pins(), which runs before the torchIndexUrl loop and so suppressed the ROCm drift check this script exists for. - A present-but-null platform section ("linux": null) passed silently, because .get() cannot tell it from an absent one. - Version components are bounded, so a pin like 3.12.99999999 - which satisfies every specifier but which uv cannot resolve to an interpreter - is rejected. - A trailing comma in requires-python is no longer read as an empty clause. Also drop the unverified 'isn't needed for the other torch backends' clause from the ROCm caveat, per review: nothing on CUDA/CPU/Windows/ARM64/MPS was smoke-tested with torch 2.12. * ci(pins): reject unreal python pins by shape, not by digit count The python pin was validated with a bounded regex, which made a bogus version merely unlikely rather than impossible: "3.12.9999" passed, and `uv python find 3.12.9999` finds no interpreter, so CI stayed green while the launcher's install broke at the last step. Replace the heuristic with two checks that make the bad values unrepresentable: - The pin must be exactly major.minor. `uv venv --python 3.12` already resolves to the newest 3.12.x, `--python 3.12.7` demands one exact build that can leave uv's index, and the launcher's reinstall check compares only major()/minor() of this field anyway. That removes the whole 3.12.<anything> family by shape. - Its major.minor must appear in project.classifiers. requires-python says which versions the metadata allows; the classifiers say which ones we ship for. Without it, an unreal version inside an open-ended requires-python (">=3.11" and a "3.99" pin) satisfies every clause and no digit bound catches it. Also fix the module docstring: only the path handed to python is location-independent, not the working directory it is typed in. Hardening found by attacking the above: - Bound the classifier pattern's digits like its two siblings. int() refuses a string of more than 4300 digits, so an unbounded pattern let a classifier raise straight out of check_python - which runs first and would have taken the torchIndexUrl checks with it. - Guard the pins.json top level. A non-object raised AttributeError from pins.get(), with the same suppressing effect (pre-existing). - Reject leading zeros, so the pin has exactly one spelling. - Report dynamic classifiers as dynamic rather than as absent. - De-duplicate classifier versions so a repeat is not listed twice. Tests assert the reason a patch pin is rejected, not just the exit code: the classifier check rejects those too, so without that a loosened version pattern would leave the suite green while advising the user to add a classifier for "3.12.7". --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> Co-authored-by: Jonathan <34005131+JPPhoto@users.noreply.github.com>
Invoke - Professional Creative AI Tools for Visual Media
Invoke is a leading creative engine built to empower professionals and enthusiasts alike. Generate and create stunning visual media using the latest AI-driven technologies. Invoke offers an industry leading web-based UI, and serves as the foundation for multiple commercial products.
- Free to use under a commercially-friendly license
- Download and install on compatible hardware
- Generate, refine, iterate on images, and build workflows
Documentation
| Quick Links |
|---|
| Installation and Updates - Documentation and Tutorials - Bug Reports - Contributing |
Installation
To get started with Invoke, Download the Launcher.
Troubleshooting, FAQ and Support
Please review our FAQ for solutions to common installation problems and other issues.
For more help, please join our Discord.
Features
Full details on features can be found in our documentation.
Web Server & UI
Invoke runs a locally hosted web server & React UI with an industry-leading user experience.
Unified Canvas
The Unified Canvas is a fully integrated canvas implementation with support for all core generation capabilities, in/out-painting, brush tools, and more. This creative tool unlocks the capability for artists to create with AI as a creative collaborator, and can be used to augment AI-generated imagery, sketches, photography, renders, and more.
Workflows & Nodes
Invoke offers a fully featured workflow management solution, enabling users to combine the power of node-based workflows with the ease of a UI. This allows for customizable generation pipelines to be developed and shared by users looking to create specific workflows to support their production use-cases.
Board & Gallery Management
Invoke features an organized gallery system for easily storing, accessing, and remixing your content in the Invoke workspace. Images can be dragged/dropped onto any Image-base UI element in the application, and rich metadata within the Image allows for easy recall of key prompts or settings used in your workflow.
Model Support
- SD 1.5
- SD 2.0
- SDXL
- SD 3.5 Medium
- SD 3.5 Large
- CogView 4
- Flux.1 Dev
- Flux.1 Schnell
- Flux.1 Kontext
- Flux.1 Krea
- Flux Redux
- Flux Fill
- Flux.2 Klein 4B
- Flux.2 Klein 9B
- Z-Image Turbo
- Z-Image Base
- Krea 2 Turbo
- Krea 2 Raw
- Anima
- Qwen Image
- Qwen Image Edit
- Ideogram 4
- ERNIE-Image
- ERNIE-Image-Turbo
- Nano Banana (API Only)
- GPT Image (API Only)
- Wan (API Only)
Other features
- Support for ckpt, diffusers, and some gguf models
- Upscaling Tools
- Embedding Manager & Support
- Model Manager & Support
- Workflow creation & management
- Node-Based Architecture
- Object Segmentation & Selection Models (SAM / SAM2)
Contributing
Anyone who wishes to contribute to this project - whether documentation, features, bug fixes, code cleanup, testing, or code reviews - is very much encouraged to do so.
Get started with contributing by reading our contribution documentation, joining the #dev-chat or the GitHub discussion board.
We hope you enjoy using Invoke as much as we enjoy creating it, and we hope you will elect to become part of our community.
Sponsors
Invoke's open-source development is powered by our sponsors. If Invoke is valuable to you or your business, please consider sponsoring us — it directly funds maintenance, new features, and community support.
We very much thank the following sponsors:
Backers ($15/mo)
Power Users ($50/mo)
Thanks
Invoke is a combined effort of passionate and talented people from across the world. We thank them for their time, hard work and effort.
Original portions of the software are Copyright © 2024 by respective contributors.