- Previously the user's preferred precision was used to select which
version branch of a diffusers model would be downloaded. Half-precision
would try to download the 'fp16' branch if it existed.
- Turns out that with waifu-diffusion this logic doesn't work, as
'fp16' gets you waifu-diffusion v1.3, while 'main' gets you
waifu-diffusion v1.4. Who knew?
- This PR adds a new optional "revision" field to `models.yaml`. This
can be used to override the diffusers branch version. In the case of
Waifu diffusion, INITIAL_MODELS.yaml now specifies the "main" branch.
- This PR also quenches the NSFW nag that downloading diffusers sometimes
triggers.
- Closes#3160
- removed app directory (a 3.0 feature), so app tests had to go too
- fixed regular expression in the concepts lib which was causing deprecation warnings
Instructions:
1. Download LoRA .safetensors files of your choice and place in
`INVOKEAIROOT/loras`. Unlike the draft version of this, the file
names can contain underscores and alphanumerics. Names with
arbitrary unicode characters are not supported.
2. Add `withLora(lora-file-basename,weight)` to your prompt. The
weight is optional and will default to 1.0. A few examples, assuming
that a LoRA file named `loras/sushi.safetensors` is present:
```
family sitting at dinner table eating sushi withLora(sushi,0.9)
family sitting at dinner table eating sushi withLora(sushi, 0.75)
family sitting at dinner table eating sushi withLora(sushi)
```
Multiple `withLora()` prompt fragments are allowed. The weight can be
arbitrarily large, but the useful range is roughly 0.5 to 1.0. Higher
weights make the LoRA's influence stronger.
In my limited testing, I found it useful to reduce the CFG to avoid
oversharpening. Also I got better results when running the LoRA on top
of the model on which it was based during training.
Don't try to load a SD 1.x-trained LoRA into a SD 2.x model, and vice
versa. You will get a nasty stack trace. This needs to be cleaned up.
3. You can change the location of the `loras` directory by passing the
`--lora_directory` option to `invokeai.
Documentation can be found in docs/features/LORAS.md.
- Allow invokeai-update to update using a release, tag or branch.
- Allow CLI's root directory update routine to update directory
contents regardless of whether current version is released.
- In model importation routine, clarify wording of instructions when user is
asked to choose the type of model being imported.
This commit fixes bugs related to the on-the-fly conversion and loading of
legacy checkpoint models built on SD-2.0 base.
- When legacy checkpoints built on SD-2.0 models were converted
on-the-fly using --ckpt_convert, generation would crash with a
precision incompatibility error.
- In addition, broken logic was causing some 2.0-derived ckpt files to
be converted into diffusers and then processed through the legacy
generation routines - not good.
- installer now installs the pretty dialog-based console launcher
- added dialogrc for custom colors
- add updater to download new launcher when users do an update
- Imported V2 legacy models will now autoconvert into diffusers
at load time regardless of setting of --ckpt_convert.
- model manager `heuristic_import()` function now looks for
side-by-side yaml and vae files for custom configuration and VAE
respectively.
Example of this:
illuminati-v1.1.safetensors
illuminati-v1.1.vae.safetensors
illuminati-v1.1.yaml
When the user tries to import `illuminati-v1.1.safetensors`, the yaml
file will be used for its configuration, and the VAE will be used for
its VAE. Conversion to diffusers will happen if needed, and the yaml
file will be used to determine which V2 format (if any) to apply.
