Merge branch 'main' into lstein/fix/multigpu-shared-weights-collect

Author: JPPhoto

.github/workflows/build-container.yml

@@ -110,6 +110,8 @@ jobs:
           build-args: |
             GPU_DRIVER=${{ matrix.gpu-driver }}
           push: ${{ github.ref == 'refs/heads/main' || github.ref_type == 'tag' || github.event.inputs.push-to-registry }}
+          provenance: mode=max
+          sbom: true
           tags: ${{ steps.meta.outputs.tags }}
           labels: ${{ steps.meta.outputs.labels }}
           # cache-from: |

.github/workflows/python-tests.yml

@@ -83,6 +83,9 @@ jobs:
               - 'invokeai/**'
               - '!invokeai/frontend/web/**'
               - 'tests/**'
+              # tests/ covers a few of these (e.g. test_check_pins.py, test_docs_json_export.py)
+              - 'scripts/**'
+              - 'pins.json'
 
       - name: setup uv
         if: ${{ steps.changed-files.outputs.python_any_changed == 'true' || inputs.always_run == true }}

.github/workflows/uv-lock-checks.yml

@@ -1,6 +1,11 @@
-# Check the `uv` lockfile for consistency with `pyproject.toml`.
+# Check the `uv` lockfile and `pins.json` for consistency with `pyproject.toml`.
 #
-# If this check fails, you should run `uv lock` to update the lockfile.
+# If the lockfile check fails, you should run `uv lock` to update the lockfile.
+# If the pins check fails, update the torch index URLs in `pins.json` to match
+# the `[[tool.uv.index]]` entries in `pyproject.toml` (see scripts/check_pins.py).
+#
+# Also checks that the lockfile keeps working for linux/aarch64, which no test job covers.
+# This reads the lockfile only - no ARM hardware or extra resolution needed.
 
 name: 'uv lock checks'
 
@@ -54,9 +59,13 @@ jobs:
             uvlock-pyprojecttoml:
               - 'pyproject.toml'
               - 'uv.lock'
+              - 'pins.json'
+              - 'scripts/check_pins.py'
+            aarch64check:
+              - 'scripts/check_aarch64_lock.py'
 
       - name: setup uv
-        if: ${{ steps.changed-files.outputs.uvlock-pyprojecttoml_any_changed == 'true' || inputs.always_run == true }}
+        if: ${{ steps.changed-files.outputs.uvlock-pyprojecttoml_any_changed == 'true' || steps.changed-files.outputs.aarch64check_any_changed == 'true' || inputs.always_run == true }}
         uses: astral-sh/setup-uv@v8.1.0
         with:
           version: '0.6.10'
@@ -66,3 +75,20 @@ jobs:
         if: ${{ steps.changed-files.outputs.uvlock-pyprojecttoml_any_changed == 'true' || inputs.always_run == true }}
         run: uv lock --locked # this will exit with 1 if the lockfile is not consistent with pyproject.toml
         shell: bash
+
+      - name: check pins.json
+        if: ${{ steps.changed-files.outputs.uvlock-pyprojecttoml_any_changed == 'true' || inputs.always_run == true }}
+        run: python3 scripts/check_pins.py # pins.json is consumed by the launcher; keep its torch index URLs in sync with pyproject.toml
+        shell: bash
+
+      - name: check aarch64 support in lockfile
+        # Also runs when the check itself changes, so edits to it are exercised.
+        if: ${{ steps.changed-files.outputs.uvlock-pyprojecttoml_any_changed == 'true' || steps.changed-files.outputs.aarch64check_any_changed == 'true' || inputs.always_run == true }}
+        # On linux/aarch64 torch and torchvision must resolve from PyPI rather than from the PyTorch WHL
+        # indexes, which have no aarch64 torchvision wheel. Several things in pyproject.toml have to hold
+        # for that, and breaking most of them leaves a lockfile with no torch at all on aarch64 while
+        # `uv lock --locked` above still passes. See the script's docstring.
+        # `--no-project` keeps `uv run` from syncing the whole project just to run this. `packaging` is
+        # capped so a future release tightening wheel-filename parsing can't change the verdict on its own.
+        run: uv run --no-project --with 'packaging<26' --python 3.12 scripts/check_aarch64_lock.py ./uv.lock
+        shell: bash

LICENSE-HiDiffusion.txt

@@ -0,0 +1,65 @@
+HiDiffusion - License notice
+
+Original project: https://github.com/megvii-research/HiDiffusion
+Vendored from:    https://github.com/monofy-org/HiDiffusion
+Vendored under:   invokeai/backend/hidiffusion/
+
+================================================================================
+CODE (Apache License 2.0)
+================================================================================
+
+The vendored HiDiffusion source code is licensed under the Apache License,
+Version 2.0. The Apache 2.0 license text is available in the root LICENSE file
+and at:
+
+    https://www.apache.org/licenses/LICENSE-2.0
+
+================================================================================
+MODULE KEYS (BSD 3-Clause License)
+================================================================================
+
+The SD 1.5 and SDXL module-key lists under
+invokeai/backend/hidiffusion/sd_module_key/ were sourced from dgenerate at:
+
+    https://github.com/Teriks/dgenerate/tree/d83b839033cc22c5101fb0f987bd4eb2de3d5d12/dgenerate/extras/hidiffusion/sd_module_key
+
+BSD 3-Clause License
+
+Copyright (c) 2023, Teriks
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+
+1. Redistributions of source code must retain the above copyright notice, this
+   list of conditions and the following disclaimer.
+
+2. Redistributions in binary form must reproduce the above copyright notice,
+   this list of conditions and the following disclaimer in the documentation
+   and/or other materials provided with the distribution.
+
+3. Neither the name of the copyright holder nor the names of its
+   contributors may be used to endorse or promote products derived from
+   this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+================================================================================
+LOCAL MODIFICATIONS
+================================================================================
+
+The following changes were applied when integrating HiDiffusion into InvokeAI:
+
+* The code was vendored under the invokeai.backend.hidiffusion package.
+* apply_hidiffusion() was extended to accept a torch.Generator, enabling
+  deterministic image generation from a seed.
+* HiDiffusion patching was integrated with InvokeAI's model loading and
+  generation lifecycle.

README.md

@@ -68,6 +68,7 @@ Invoke features an organized gallery system for easily storing, accessing, and r
 - Flux.1 Krea
 - Flux Redux
 - Flux Fill
+- Flux.2 Dev
 - Flux.2 Klein 4B
 - Flux.2 Klein 9B
 - Z-Image Turbo
@@ -121,6 +122,7 @@ We very much thank the following sponsors:
 ### Power Users ($50/mo)
 
 * [mickr777](https://github.com/mickr777)
+* [Astroburner](https://github.com/Astroburner)
 
 ## Thanks
 

docs/src/content/docs/development/Guides/creating-nodes.mdx

@@ -49,6 +49,7 @@ Because the whole node is moved to another device, only mark a node `idle_gpu_of
 - **It is encoder-only.** Its sole GPU work is loading one or more encoder models and running their forward pass. It must not load or run the denoise/transformer or VAE, or do any other work tied to the session's own GPU.
 - **It stores its result on the CPU before returning.** Move output tensors to the CPU (`tensor.detach().to("cpu")`) and save them as conditioning/tensors. The denoiser picks them up and moves them onto its own GPU later — this is what makes the cross-GPU handoff safe and device-agnostic.
 - **It places inputs on the loaded model's device, not a fixed device.** Resolve the device from the model you just loaded (e.g. `get_effective_device(model)` from `invokeai.backend.model_manager.load.model_cache.utils`, or `TorchDevice.choose_torch_device()`), rather than hard-coding `cuda:0`. The built-in `flux_text_encoder` and `compel` nodes are good references.
+- **Its runtime is dominated by that forward pass.** The borrow holds the lent GPU's lock for the whole node, and a session dequeued onto that GPU blocks until it is released. Model caches are per-device, so the first borrow of a GPU cold-loads the encoder there — that cost is paid once and then amortizes across later borrows, which hit the cache. Work that recurs on *every* execution does not amortize, so a node that runs something open-ended per call (an autoregressive `generate()` loop, say) will stall the lent GPU again on every generation. If your node has both kinds of work, split them: `ernie_image_prompt_enhancer` was carved out of `ernie_image_text_encoder` for exactly this reason, leaving the encoder offloadable and keeping the enhancer's `generate()` on the session's own GPU.
 
 :::caution[Only mark encoder-only nodes]
 If a node that also runs the denoiser, VAE, or other session-GPU work is marked `idle_gpu_offloadable=True`, that work will be re-pinned to the wrong GPU and can misplace tensors or raise device-mismatch errors. When in doubt, leave it unset (the default is `False`) — the node will still work correctly, just without the offload optimization.

docs/src/content/docs/features/Canvas/bounding-box.mdx

@@ -0,0 +1,49 @@
+---
+title: Generation Bounding Box
+description: Learn how the bounding box defines the Canvas generation area and the image context sent to the model.
+lastUpdated: 2026-08-02
+sidebar:
+  order: 0
+---
+
+The **generation bounding box** is the rectangle that defines where a Canvas generation takes place. It controls both
+the area returned by the model and the portion of the Canvas used as image context for that generation.
+
+## What the Model Sees
+
+When you click **Invoke**, the visible Canvas content inside the bounding box is composited and sent through the
+generation pipeline. Content outside the box is not included in that Canvas image input, even though it remains visible
+to you on the larger Canvas.
+
+This makes placement important. If the model needs to continue a shape, match a texture, or preserve part of a subject,
+include enough of that content inside the bounding box to give the model useful context. Moving the box changes which
+part of the image the model can use for the next generation.
+
+:::note
+The bounding box defines the generation area; it is not an inpaint mask. Use an **Inpaint Mask** when only selected
+parts inside the box should be regenerated.
+:::
+
+## Move and Resize the Bounding Box
+
+Select the **Bounding Box** tool in the Canvas toolbar. You can then:
+
+- Drag inside the box to move it.
+- Drag its handles to resize it.
+- Use the aspect-ratio lock when you need to preserve its current proportions.
+
+The bounding box dimensions determine the generated image's width and height. Invoke constrains these dimensions to
+values supported by the selected model.
+
+:::tip[Tap & Hold C]
+Tap <kbd>C</kbd> to keep the **Bounding Box** tool selected. Hold <kbd>C</kbd> to use it temporarily, then release the
+key to return to your previous tool. The shortcut can be changed in the **Hotkeys** settings.
+:::
+
+## Bounding Box Size and Processing Size
+
+The bounding box is the final footprint of the generation on the Canvas. If **Scale Before Processing** is enabled,
+Invoke may process that area at a different resolution and then resize the result back to the bounding box dimensions.
+
+For best results, choose a box large enough to include the visual context the model needs, while keeping its dimensions
+appropriate for the selected model and your available VRAM.

docs/src/content/docs/features/hidiffusion.mdx

@@ -0,0 +1,39 @@
+---
+title: HiDiffusion
+---
+
+# HiDiffusion
+
+HiDiffusion is an optional denoising enhancement that can improve detail and structure at higher resolutions for SD 1.5, SD 2.1, and SDXL. It modifies the UNet during denoising and is most noticeable at 1536px and above.
+
+The vendored implementation includes module-key definitions for SD 1.5 and SDXL. SD 2.1 intentionally reuses the SD 1.5 module-key mapping.
+
+Learn more: https://github.com/megvii-research/HiDiffusion
+
+## Where to find the switches
+
+1. Open the **Canvas** tab.
+2. Expand **Advanced Settings**.
+3. In the **Advanced** grid, enable **HiDiffusion** and optionally adjust the two sub‑toggles and ratios:
+   - **HiDiffusion: RAU‑Net**
+   - **HiDiffusion: Window Attention**
+   - **HiDiffusion: T1 Ratio**
+   - **HiDiffusion: T2 Ratio**
+
+## What the switches do
+
+- **HiDiffusion**: Enables the HiDiffusion patch for denoising. Use this for high‑resolution generations; the effect is subtle at lower sizes.
+
+- **HiDiffusion: RAU‑Net**: Enables RAU‑Net blocks. This typically improves structure and mid‑frequency detail, especially at larger resolutions.
+
+- **HiDiffusion: Window Attention**: Enables windowed attention blocks. This can boost local texture/detail, but may slightly affect global coherence in some prompts.
+
+- **HiDiffusion: T1 Ratio**: Controls when HiDiffusion switches into its mid‑stage behavior. Lower values switch earlier; higher values preserve global structure longer.
+
+- **HiDiffusion: T2 Ratio**: Controls when HiDiffusion switches into its late‑stage behavior. Higher values keep window attention active longer and can sharpen local detail.
+
+## Tips
+
+- Try **1536–2048 px** for the clearest benefits (SDXL).
+- If results look worse, disable **Window Attention** first, then RAU‑Net.
+- Effects vary by scheduler and model; compare with the same seed for a fair test.

docs/src/content/docs/features/krea-2.mdx

@@ -64,12 +64,32 @@ transform the text conditioning and are especially useful for the distilled Turb
   prompt adherence for variety.
 
 Both are recorded in image metadata and can be recalled.
+When enabled on the canvas, the same enhancer chain is applied independently to the global prompt and
+each positive regional prompt before their conditionings are collected.
 
 ## Multiple conditionings
 
 In the workflow editor, the **Denoise - Krea-2** node accepts one conditioning or a collection for both
 its positive and negative conditioning inputs. Multiple independently encoded conditionings are concatenated
-after padding tokens are removed. They are global conditionings; spatial masks are not supported.
+after padding tokens are removed.
+
+The **Text Encoder - Krea-2** node also accepts an optional mask. A masked conditioning applies to that
+image region; an unmasked conditioning applies to the background not covered by any regional mask. If
+regional masks cover the full image, an unmasked conditioning falls back to the full image instead of being
+ignored. Krea-2 uses restricted attention on alternating main transformer blocks, leaving the other blocks
+unrestricted to preserve image-wide coherence. Positive regional prompts are available on the canvas. In
+workflows, masked conditioning collections can also be supplied to the negative input when CFG is enabled.
+Canvas regional negative prompts, auto-negative, and regional reference images are not supported.
+
+:::caution[Regional prompting memory]
+Regional prompting builds a dense boolean attention mask whose memory grows quadratically with the combined
+text and image token count. Invoke reserves memory for retained masks, construction scratch space, and the
+dtype-sized additive attention bias created by SDPA. Fused memory-efficient attention support for dense masks
+still depends on the GPU, PyTorch build, dtype, and sequence shape. When no fused kernel is available, PyTorch
+falls back to math attention, which may use substantially more VRAM and can cause an out-of-memory error.
+Reducing image resolution or disabling regional prompting is the practical fallback. Automated CUDA coverage
+is skipped on unsupported hardware and cannot exercise every GPU/backend combination.
+:::
 
 ## LoRA
 

docs/src/content/docs/start-here/manual.mdx

@@ -131,6 +131,16 @@ The following commands vary depending on the version of Invoke being installed a
               ```sh
               --torch-backend=rocm7.1
               ```
+
+              :::caution[ROCm and torch 2.12]
+                The `rocm7.1` index currently defaults to torch 2.12.x, which has been reported to
+                break generation on ROCm ([#9410](https://github.com/invoke-ai/InvokeAI/issues/9410)).
+                Until that issue is closed, also constrain torch when installing:
+                ```sh
+                uv pip install <PACKAGE_SPECIFIER>==<VERSION> "torch<2.12" --python 3.12 --python-preference only-managed --torch-backend=rocm7.1 --force-reinstall
+                ```
+                This workaround applies to the reported ROCm case only.
+              :::
             </TabItem>
             <TabItem label="All other cases">
               Do not use a torch backend.
@@ -181,7 +191,7 @@ The following commands vary depending on the version of Invoke being installed a
         </TabItem>
         <TabItem label="Linux/MacOS" icon="linux">
           ```bash
-          invokeai-web --root $Home/invokeai
+          invokeai-web --root ~/invokeai
           ```
         </TabItem>
       </Tabs>