b7938d9ca9
* fix(config): fix typing issues in `config/` `config/invokeai_config.py`: - use `Optional` for things that are optional - fix typing of `ram_cache_size()` and `vram_cache_size()` - remove unused and incorrectly typed method `autoconvert_path` - fix types and logic for `parse_args()`, in which `InvokeAIAppConfig.initconf` *must* be a `DictConfig`, but function would allow it to be set as a `ListConfig`, which presumably would cause issues elsewhere `config/base.py`: - use `cls` for first arg of class methods - use `Optional` for things that are optional - fix minor type issue related to setting of `env_prefix` - remove unused `add_subparser()` method, which calls `add_parser()` on an `ArgumentParser` (method only available on the `_SubParsersAction` object, which is returned from ArgumentParser.add_subparsers()`) * feat: queued generation and batches Due to a very messy branch with broad addition of `isort` on `main` alongside it, some git surgery was needed to get an agreeable git history. This commit represents all of the work on queued generation. See PR for notes. * chore: flake8, isort, black * fix(nodes): fix incorrect service stop() method * fix(nodes): improve names of a few variables * fix(tests): fix up tests after changes to batches/queue * feat(tests): add unit tests for session queue helper functions * feat(ui): dynamic prompts is always enabled * feat(queue): add queue_status_changed event * feat(ui): wip queue graphs * feat(nodes): move cleanup til after invoker startup * feat(nodes): add cancel_by_batch_ids * feat(ui): wip batch graphs & UI * fix(nodes): remove `Batch.batch_id` from required * fix(ui): cleanup and use fixedCacheKey for all mutations * fix(ui): remove orphaned nodes from canvas graphs * fix(nodes): fix cancel_by_batch_ids result count * fix(ui): only show cancel batch tooltip when batches were canceled * chore: isort * fix(api): return `[""]` when dynamic prompts generates no prompts Just a simple fallback so we always have a prompt. * feat(ui): dynamicPrompts.combinatorial is always on There seems to be little purpose in using the combinatorial generation for dynamic prompts. I've disabled it by hiding it from the UI and defaulting combinatorial to true. If we want to enable it again in the future it's straightforward to do so. * feat: add queue_id & support logic * feat(ui): fix upscale button It prepends the upscale operation to queue * feat(nodes): return queue item when enqueuing a single graph This facilitates one-off graph async workflows in the client. * feat(ui): move controlnet autoprocess to queue * fix(ui): fix non-serializable DOMRect in redux state * feat(ui): QueueTable performance tweaks * feat(ui): update queue list Queue items expand to show the full queue item. Just as JSON for now. * wip threaded session_processor * feat(nodes,ui): fully migrate queue to session_processor * feat(nodes,ui): add processor events * feat(ui): ui tweaks * feat(nodes,ui): consolidate events, reduce network requests * feat(ui): cleanup & abstract queue hooks * feat(nodes): optimize batch permutation Use a generator to do only as much work as is needed. Previously, though we only ended up creating exactly as many queue items as was needed, there was still some intermediary work that calculated *all* permutations. When that number was very high, the system had a very hard time and used a lot of memory. The logic has been refactored to use a generator. Additionally, the batch validators are optimized to return early and use less memory. * feat(ui): add seed behaviour parameter This dynamic prompts parameter allows the seed to be randomized per prompt or per iteration: - Per iteration: Use the same seed for all prompts in a single dynamic prompt expansion - Per prompt: Use a different seed for every single prompt "Per iteration" is appropriate for exploring a the latents space with a stable starting noise, while "Per prompt" provides more variation. * fix(ui): remove extraneous random seed nodes from linear graphs * fix(ui): fix controlnet autoprocess not working when queue is running * feat(queue): add timestamps to queue status updates Also show execution time in queue list * feat(queue): change all execution-related events to use the `queue_id` as the room, also include `queue_item_id` in InvocationQueueItem This allows for much simpler handling of queue items. * feat(api): deprecate sessions router * chore(backend): tidy logging in `dependencies.py` * fix(backend): respect `use_memory_db` * feat(backend): add `config.log_sql` (enables sql trace logging) * feat: add invocation cache Supersedes #4574 The invocation cache provides simple node memoization functionality. Nodes that use the cache are memoized and not re-executed if their inputs haven't changed. Instead, the stored output is returned. ## Results This feature provides anywhere some significant to massive performance improvement. The improvement is most marked on large batches of generations where you only change a couple things (e.g. different seed or prompt for each iteration) and low-VRAM systems, where skipping an extraneous model load is a big deal. ## Overview A new `invocation_cache` service is added to handle the caching. There's not much to it. All nodes now inherit a boolean `use_cache` field from `BaseInvocation`. This is a node field and not a class attribute, because specific instances of nodes may want to opt in or out of caching. The recently-added `invoke_internal()` method on `BaseInvocation` is used as an entrypoint for the cache logic. To create a cache key, the invocation is first serialized using pydantic's provided `json()` method, skipping the unique `id` field. Then python's very fast builtin `hash()` is used to create an integer key. All implementations of `InvocationCacheBase` must provide a class method `create_key()` which accepts an invocation and outputs a string or integer key. ## In-Memory Implementation An in-memory implementation is provided. In this implementation, the node outputs are stored in memory as python classes. The in-memory cache does not persist application restarts. Max node cache size is added as `node_cache_size` under the `Generation` config category. It defaults to 512 - this number is up for discussion, but given that these are relatively lightweight pydantic models, I think it's safe to up this even higher. Note that the cache isn't storing the big stuff - tensors and images are store on disk, and outputs include only references to them. ## Node Definition The default for all nodes is to use the cache. The `@invocation` decorator now accepts an optional `use_cache: bool` argument to override the default of `True`. Non-deterministic nodes, however, should set this to `False`. Currently, all random-stuff nodes, including `dynamic_prompt`, are set to `False`. The field name `use_cache` is now effectively a reserved field name and possibly a breaking change if any community nodes use this as a field name. In hindsight, all our reserved field names should have been prefixed with underscores or something. ## One Gotcha Leaf nodes probably want to opt out of the cache, because if they are not cached, their outputs are not saved again. If you run the same graph multiple times, you only end up with a single image output, because the image storage side-effects are in the `invoke()` method, which is bypassed if we have a cache hit. ## Linear UI The linear graphs _almost_ just work, but due to the gotcha, we need to be careful about the final image-outputting node. To resolve this, a `SaveImageInvocation` node is added and used in the linear graphs. This node is similar to `ImagePrimitive`, except it saves a copy of its input image, and has `use_cache` set to `False` by default. This is now the leaf node in all linear graphs, and is the only node in those graphs with `use_cache == False` _and_ the only node with `is_intermedate == False`. ## Workflow Editor All nodes now have a footer with a new `Use Cache [ ]` checkbox. It defaults to the value set by the invocation in its python definition, but can be changed by the user. The workflow/node validation logic has been updated to migrate old workflows to use the new default values for `use_cache`. Users may still want to review the settings that have been chosen. In the event of catastrophic failure when running this migration, the default value of `True` is applied, as this is correct for most nodes. Users should consider saving their workflows after loading them in and having them updated. ## Future Enhancements - Callback A future enhancement would be to provide a callback to the `use_cache` flag that would be run as the node is executed to determine, based on its own internal state, if the cache should be used or not. This would be useful for `DynamicPromptInvocation`, where the deterministic behaviour is determined by the `combinatorial: bool` field. ## Future Enhancements - Persisted Cache Similar to how the latents storage is backed by disk, the invocation cache could be persisted to the database or disk. We'd need to be very careful about deserializing outputs, but it's perhaps worth exploring in the future. * fix(ui): fix queue list item width * feat(nodes): do not send the whole node on every generator progress * feat(ui): strip out old logic related to sessions Things like `isProcessing` are no longer relevant with queue. Removed them all & updated everything be appropriate for queue. May be a few little quirks I've missed... * feat(ui): fix up param collapse labels * feat(ui): click queue count to go to queue tab * tidy(queue): update comment, query format * feat(ui): fix progress bar when canceling * fix(ui): fix circular dependency * feat(nodes): bail on node caching logic if `node_cache_size == 0` * feat(nodes): handle KeyError on node cache pop * feat(nodes): bypass cache codepath if caches is disabled more better no do thing * fix(ui): reset api cache on connect/disconnect * feat(ui): prevent enqueue when no prompts generated * feat(ui): add queue controls to workflow editor * feat(ui): update floating buttons & other incidental UI tweaks * fix(ui): fix missing/incorrect translation keys * fix(tests): add config service to mock invocation services invoking needs access to `node_cache_size` to occur * optionally remove pause/resume buttons from queue UI * option to disable prepending * chore(ui): remove unused file * feat(queue): remove `order_id` entirely, `item_id` is now an autoinc pk --------- Co-authored-by: Mary Hipp <maryhipp@Marys-MacBook-Air.local> |
||
|---|---|---|
| .dev_scripts | ||
| .github | ||
| coverage | ||
| docker | ||
| docs | ||
| installer | ||
| invokeai | ||
| scripts | ||
| tests | ||
| .dockerignore | ||
| .editorconfig | ||
| .git-blame-ignore-revs | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| .pre-commit-config.yaml | ||
| .prettierrc.yaml | ||
| CODE_OF_CONDUCT.md | ||
| flake.lock | ||
| flake.nix | ||
| InvokeAI_Statement_of_Values.md | ||
| LICENSE | ||
| LICENSE-SD1+SD2.txt | ||
| LICENSE-SDXL.txt | ||
| mkdocs.yml | ||
| pyproject.toml | ||
| README.md | ||
| Stable_Diffusion_v1_Model_Card.md | ||
Invoke AI - Generative AI for Professional Creatives
Professional Creative Tools for Stable Diffusion, Custom-Trained Models, and more.
To learn more about Invoke AI, get started instantly, or implement our Business solutions, visit invoke.ai
InvokeAI is a leading creative engine built to empower professionals and enthusiasts alike. Generate and create stunning visual media using the latest AI-driven technologies. InvokeAI offers an industry leading Web Interface, interactive Command Line Interface, and also serves as the foundation for multiple commercial products.
Quick links: [How to Install] [Discord Server] [Documentation and Tutorials] [Bug Reports] [Discussion, Ideas & Q&A] [Contributing]
Table of Contents
Table of Contents 📝
Getting Started
More About Invoke
Supporting the Project
- 🤝 Contributing
- 👥 Contributors
- 💕 Support
Quick Start
For full installation and upgrade instructions, please see: InvokeAI Installation Overview
If upgrading from version 2.3, please read Migrating a 2.3 root directory to 3.0 first.
Automatic Installer (suggested for 1st time users)
-
Go to the bottom of the Latest Release Page
-
Download the .zip file for your OS (Windows/macOS/Linux).
-
Unzip the file.
-
Windows: double-click on the
install.batscript. macOS: Open a Terminal window, drag the fileinstall.shfrom Finder into the Terminal, and press return. Linux: runinstall.sh. -
You'll be asked to confirm the location of the folder in which to install InvokeAI and its image generation model files. Pick a location with at least 15 GB of free memory. More if you plan on installing lots of models.
-
Wait while the installer does its thing. After installing the software, the installer will launch a script that lets you configure InvokeAI and select a set of starting image generation models.
-
Find the folder that InvokeAI was installed into (it is not the same as the unpacked zip file directory!) The default location of this folder (if you didn't change it in step 5) is
~/invokeaion Linux/Mac systems, andC:\Users\YourName\invokeaion Windows. This directory will contain launcher scripts namedinvoke.shandinvoke.bat. -
On Windows systems, double-click on the
invoke.batfile. On macOS, open a Terminal window, draginvoke.shfrom the folder into the Terminal, and press return. On Linux, runinvoke.sh -
Press 2 to open the "browser-based UI", press enter/return, wait a minute or two for Stable Diffusion to start up, then open your browser and go to http://localhost:9090.
-
Type
banana sushiin the box on the top left and clickInvoke
Command-Line Installation (for developers and users familiar with Terminals)
You must have Python 3.9 through 3.11 installed on your machine. Earlier or
later versions are not supported.
Node.js also needs to be installed along with yarn (can be installed with
the command npm install -g yarn if needed)
-
Open a command-line window on your machine. The PowerShell is recommended for Windows.
-
Create a directory to install InvokeAI into. You'll need at least 15 GB of free space:
mkdir invokeai -
Create a virtual environment named
.venvinside this directory and activate it:cd invokeai python -m venv .venv --prompt InvokeAI -
Activate the virtual environment (do it every time you run InvokeAI)
For Linux/Mac users:
source .venv/bin/activateFor Windows users:
.venv\Scripts\activate -
Install the InvokeAI module and its dependencies. Choose the command suited for your platform & GPU.
For Windows/Linux with an NVIDIA GPU:
pip install "InvokeAI[xformers]" --use-pep517 --extra-index-url https://download.pytorch.org/whl/cu118For Linux with an AMD GPU:
pip install InvokeAI --use-pep517 --extra-index-url https://download.pytorch.org/whl/rocm5.4.2For non-GPU systems:
pip install InvokeAI --use-pep517 --extra-index-url https://download.pytorch.org/whl/cpuFor Macintoshes, either Intel or M1/M2:
pip install InvokeAI --use-pep517 -
Configure InvokeAI and install a starting set of image generation models (you only need to do this once):
invokeai-configure --root .Don't miss the dot at the end!
-
Launch the web server (do it every time you run InvokeAI):
invokeai-web -
Point your browser to http://localhost:9090 to bring up the web interface.
-
Type
banana sushiin the box on the top left and clickInvoke.
Be sure to activate the virtual environment each time before re-launching InvokeAI,
using source .venv/bin/activate or .venv\Scripts\activate.
Detailed Installation Instructions
This fork is supported across Linux, Windows and Macintosh. Linux users can use either an Nvidia-based card (with CUDA support) or an AMD card (using the ROCm driver). For full installation and upgrade instructions, please see: InvokeAI Installation Overview
Migrating a v2.3 InvokeAI root directory
The InvokeAI root directory is where the InvokeAI startup file,
installed models, and generated images are stored. It is ordinarily
named invokeai and located in your home directory. The contents and
layout of this directory has changed between versions 2.3 and 3.0 and
cannot be used directly.
We currently recommend that you use the installer to create a new root
directory named differently from the 2.3 one, e.g. invokeai-3 and
then use a migration script to copy your 2.3 models into the new
location. However, if you choose, you can upgrade this directory in
place. This section gives both recipes.
Creating a new root directory and migrating old models
This is the safer recipe because it leaves your old root directory in place to fall back on.
-
Follow the instructions above to create and install InvokeAI in a directory that has a different name from the 2.3 invokeai directory. In this example, we will use "invokeai-3"
-
When you are prompted to select models to install, select a minimal set of models, such as stable-diffusion-v1.5 only.
-
After installation is complete launch
invokeai.sh(Linux/Mac) orinvokeai.batand select option 8 "Open the developers console". This will take you to the command line. -
Issue the command
invokeai-migrate3 --from /path/to/v2.3-root --to /path/to/invokeai-3-root. Provide the correct--fromand--topaths for your v2.3 and v3.0 root directories respectively.
This will copy and convert your old models from 2.3 format to 3.0
format and create a new models directory in the 3.0 directory. The
old models directory (which contains the models selected at install
time) will be renamed models.orig and can be deleted once you have
confirmed that the migration was successful.
If you wish, you can pass the 2.3 root directory to both --from and
--to in order to update in place. Warning: this directory will no
longer be usable with InvokeAI 2.3.
Migrating in place
For the adventurous, you may do an in-place upgrade from 2.3 to 3.0 without touching the command line. *This recipe does not work on Windows platforms due to a bug in the Windows version of the 2.3 upgrade script. See the next section for a Windows recipe.
For Mac and Linux Users:
-
Launch the InvokeAI launcher script in your current v2.3 root directory.
-
Select option [9] "Update InvokeAI" to bring up the updater dialog.
-
Select option [1] to upgrade to the latest release.
-
Once the upgrade is finished you will be returned to the launcher menu. Select option [7] "Re-run the configure script to fix a broken install or to complete a major upgrade".
This will run the configure script against the v2.3 directory and update it to the 3.0 format. The following files will be replaced:
- The invokeai.init file, replaced by invokeai.yaml
- The models directory
- The configs/models.yaml model index
The original versions of these files will be saved with the suffix ".orig" appended to the end. Once you have confirmed that the upgrade worked, you can safely remove these files. Alternatively you can restore a working v2.3 directory by removing the new files and restoring the ".orig" files' original names.
For Windows Users:
Windows Users can upgrade with the
- Enter the 2.3 root directory you wish to upgrade
- Launch
invoke.shorinvoke.bat - Select the "Developer's console" option [8]
- Type the following commands
pip install "invokeai @ https://github.com/invoke-ai/InvokeAI/archive/refs/tags/v3.0.0" --use-pep517 --upgrade
invokeai-configure --root .
(Replace v3.0.0 with the current release number if this document is out of date).
The first command will install and upgrade new software to run InvokeAI. The second will prepare the 2.3 directory for use with 3.0. You may now launch the WebUI in the usual way, by selecting option [1] from the launcher script
Migrating Images
The migration script will migrate your invokeai settings and models, including textual inversion models, LoRAs and merges that you may have installed previously. However it does not migrate the generated images stored in your 2.3-format outputs directory. To do this, you need to run an additional step:
-
From a working InvokeAI 3.0 root directory, start the launcher and enter menu option [8] to open the "developer's console".
-
At the developer's console command line, type the command:
invokeai-import-images
- This will lead you through the process of confirming the desired source and destination for the imported images. The images will appear in the gallery board of your choice, and contain the original prompt, model name, and other parameters used to generate the image.
(Many kudos to techjedi for contributing this script.)
Hardware Requirements
InvokeAI is supported across Linux, Windows and macOS. Linux users can use either an Nvidia-based card (with CUDA support) or an AMD card (using the ROCm driver).
System
You will need one of the following:
- An NVIDIA-based graphics card with 4 GB or more VRAM memory. 6-8 GB of VRAM is highly recommended for rendering using the Stable Diffusion XL models
- An Apple computer with an M1 chip.
- An AMD-based graphics card with 4GB or more VRAM memory (Linux only), 6-8 GB for XL rendering.
We do not recommend the GTX 1650 or 1660 series video cards. They are unable to run in half-precision mode and do not have sufficient VRAM to render 512x512 images.
Memory - At least 12 GB Main Memory RAM.
Disk - At least 12 GB of free disk space for the machine learning model, Python, and all its dependencies.
Features
Feature documentation can be reviewed by navigating to the InvokeAI Documentation page
Web Server & UI
InvokeAI offers a locally hosted Web Server & React Frontend, with an industry leading user experience. The Web-based UI allows for simple and intuitive workflows, and is responsive for use on mobile devices and tablets accessing the web server.
Unified Canvas
The Unified Canvas is a fully integrated canvas implementation with support for all core generation capabilities, in/outpainting, 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
InvokeAI offers a fully featured workflow management solution, enabling users to combine the power of nodes based workflows with the easy 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 AI provides 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.
Other features
- Support for both ckpt and diffusers models
- SD 2.0, 2.1, XL support
- Upscaling Tools
- Embedding Manager & Support
- Model Manager & Support
- Workflow creation & management
- Node-Based Architecture
Latest Changes
For our latest changes, view our Release Notes and the CHANGELOG.
Troubleshooting
Please check out our Q&A to get solutions for common installation problems and other issues. For more help, please join our Discord
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.
If you are unfamiliar with how to contribute to GitHub projects, we have a new contributor checklist you can follow to get started contributing: New Contributor Checklist.
We hope you enjoy using our software as much as we enjoy creating it, and we hope that some of those of you who are reading this will elect to become part of our community.
Welcome to InvokeAI!
Contributors
This fork is a combined effort of various people from across the world. Check out the list of all these amazing people. We thank them for their time, hard work and effort.
Support
For support, please use this repository's GitHub Issues tracking service, or join the Discord.
Original portions of the software are Copyright (c) 2023 by respective contributors.