You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Add draft for lora text encoder scale
* Improve naming
* fix: training dreambooth lora script.
* Apply suggestions from code review
* Update examples/dreambooth/train_dreambooth_lora.py
* Apply suggestions from code review
* Apply suggestions from code review
* add lora mixin when fit
* add lora mixin when fit
* add lora mixin when fit
* fix more
* fix more
---------
Co-authored-by: Sayak Paul <[email protected]>
Copy file name to clipboardexpand all lines: CONTRIBUTING.md
+4-4
Original file line number
Diff line number
Diff line change
@@ -125,14 +125,14 @@ Awesome! Tell us what problem it solved for you.
125
125
126
126
You can open a feature request [here](https://github.com/huggingface/diffusers/issues/new?assignees=&labels=&template=feature_request.md&title=).
127
127
128
-
#### 2.3 Feedback.
128
+
#### 2.3 Feedback.
129
129
130
130
Feedback about the library design and why it is good or not good helps the core maintainers immensely to build a user-friendly library. To understand the philosophy behind the current design philosophy, please have a look [here](https://huggingface.co/docs/diffusers/conceptual/philosophy). If you feel like a certain design choice does not fit with the current design philosophy, please explain why and how it should be changed. If a certain design choice follows the design philosophy too much, hence restricting use cases, explain why and how it should be changed.
131
131
If a certain design choice is very useful for you, please also leave a note as this is great feedback for future design decisions.
132
132
133
133
You can open an issue about feedback [here](https://github.com/huggingface/diffusers/issues/new?assignees=&labels=&template=feedback.md&title=).
134
134
135
-
#### 2.4 Technical questions.
135
+
#### 2.4 Technical questions.
136
136
137
137
Technical questions are mainly about why certain code of the library was written in a certain way, or what a certain part of the code does. Please make sure to link to the code in question and please provide detail on
138
138
why this part of the code is difficult to understand.
@@ -394,8 +394,8 @@ passes. You should run the tests impacted by your changes like this:
394
394
```bash
395
395
$ pytest tests/<TEST_TO_RUN>.py
396
396
```
397
-
398
-
Before you run the tests, please make sure you install the dependencies required for testing. You can do so
397
+
398
+
Before you run the tests, please make sure you install the dependencies required for testing. You can do so
Copy file name to clipboardexpand all lines: PHILOSOPHY.md
+10-10
Original file line number
Diff line number
Diff line change
@@ -27,18 +27,18 @@ In a nutshell, Diffusers is built to be a natural extension of PyTorch. Therefor
27
27
28
28
## Simple over easy
29
29
30
-
As PyTorch states, **explicit is better than implicit** and **simple is better than complex**. This design philosophy is reflected in multiple parts of the library:
30
+
As PyTorch states, **explicit is better than implicit** and **simple is better than complex**. This design philosophy is reflected in multiple parts of the library:
31
31
- We follow PyTorch's API with methods like [`DiffusionPipeline.to`](https://huggingface.co/docs/diffusers/main/en/api/diffusion_pipeline#diffusers.DiffusionPipeline.to) to let the user handle device management.
32
32
- Raising concise error messages is preferred to silently correct erroneous input. Diffusers aims at teaching the user, rather than making the library as easy to use as possible.
33
33
- Complex model vs. scheduler logic is exposed instead of magically handled inside. Schedulers/Samplers are separated from diffusion models with minimal dependencies on each other. This forces the user to write the unrolled denoising loop. However, the separation allows for easier debugging and gives the user more control over adapting the denoising process or switching out diffusion models or schedulers.
34
-
- Separately trained components of the diffusion pipeline, *e.g.* the text encoder, the unet, and the variational autoencoder, each have their own model class. This forces the user to handle the interaction between the different model components, and the serialization format separates the model components into different files. However, this allows for easier debugging and customization. Dreambooth or textual inversion training
34
+
- Separately trained components of the diffusion pipeline, *e.g.* the text encoder, the unet, and the variational autoencoder, each have their own model class. This forces the user to handle the interaction between the different model components, and the serialization format separates the model components into different files. However, this allows for easier debugging and customization. Dreambooth or textual inversion training
35
35
is very simple thanks to diffusers' ability to separate single components of the diffusion pipeline.
36
36
37
37
## Tweakable, contributor-friendly over abstraction
38
38
39
-
For large parts of the library, Diffusers adopts an important design principle of the [Transformers library](https://github.com/huggingface/transformers), which is to prefer copy-pasted code over hasty abstractions. This design principle is very opinionated and stands in stark contrast to popular design principles such as [Don't repeat yourself (DRY)](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself).
39
+
For large parts of the library, Diffusers adopts an important design principle of the [Transformers library](https://github.com/huggingface/transformers), which is to prefer copy-pasted code over hasty abstractions. This design principle is very opinionated and stands in stark contrast to popular design principles such as [Don't repeat yourself (DRY)](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself).
40
40
In short, just like Transformers does for modeling files, diffusers prefers to keep an extremely low level of abstraction and very self-contained code for pipelines and schedulers.
41
-
Functions, long code blocks, and even classes can be copied across multiple files which at first can look like a bad, sloppy design choice that makes the library unmaintainable.
41
+
Functions, long code blocks, and even classes can be copied across multiple files which at first can look like a bad, sloppy design choice that makes the library unmaintainable.
42
42
**However**, this design has proven to be extremely successful for Transformers and makes a lot of sense for community-driven, open-source machine learning libraries because:
43
43
- Machine Learning is an extremely fast-moving field in which paradigms, model architectures, and algorithms are changing rapidly, which therefore makes it very difficult to define long-lasting code abstractions.
44
44
- Machine Learning practitioners like to be able to quickly tweak existing code for ideation and research and therefore prefer self-contained code over one that contains many abstractions.
@@ -47,10 +47,10 @@ Functions, long code blocks, and even classes can be copied across multiple file
47
47
At Hugging Face, we call this design the **single-file policy** which means that almost all of the code of a certain class should be written in a single, self-contained file. To read more about the philosophy, you can have a look
48
48
at [this blog post](https://huggingface.co/blog/transformers-design-philosophy).
49
49
50
-
In diffusers, we follow this philosophy for both pipelines and schedulers, but only partly for diffusion models. The reason we don't follow this design fully for diffusion models is because almost all diffusion pipelines, such
50
+
In diffusers, we follow this philosophy for both pipelines and schedulers, but only partly for diffusion models. The reason we don't follow this design fully for diffusion models is because almost all diffusion pipelines, such
51
51
as [DDPM](https://huggingface.co/docs/diffusers/v0.12.0/en/api/pipelines/ddpm), [Stable Diffusion](https://huggingface.co/docs/diffusers/v0.12.0/en/api/pipelines/stable_diffusion/overview#stable-diffusion-pipelines), [UnCLIP (Dalle-2)](https://huggingface.co/docs/diffusers/v0.12.0/en/api/pipelines/unclip#overview) and [Imagen](https://imagen.research.google/) all rely on the same diffusion model, the [UNet](https://huggingface.co/docs/diffusers/api/models#diffusers.UNet2DConditionModel).
52
52
53
-
Great, now you should have generally understood why 🧨 Diffusers is designed the way it is 🤗.
53
+
Great, now you should have generally understood why 🧨 Diffusers is designed the way it is 🤗.
54
54
We try to apply these design principles consistently across the library. Nevertheless, there are some minor exceptions to the philosophy or some unlucky design choices. If you have feedback regarding the design, we would ❤️ to hear it [directly on GitHub](https://github.com/huggingface/diffusers/issues/new?assignees=&labels=&template=feedback.md&title=).
55
55
56
56
## Design Philosophy in Details
@@ -89,17 +89,17 @@ The following design principles are followed:
89
89
- Models should by default have the highest precision and lowest performance setting.
90
90
- To integrate new model checkpoints whose general architecture can be classified as an architecture that already exists in Diffusers, the existing model architecture shall be adapted to make it work with the new checkpoint. One should only create a new file if the model architecture is fundamentally different.
91
91
- Models should be designed to be easily extendable to future changes. This can be achieved by limiting public function arguments, configuration arguments, and "foreseeing" future changes, *e.g.* it is usually better to add `string` "...type" arguments that can easily be extended to new future types instead of boolean `is_..._type` arguments. Only the minimum amount of changes shall be made to existing architectures to make a new model checkpoint work.
92
-
- The model design is a difficult trade-off between keeping code readable and concise and supporting many model checkpoints. For most parts of the modeling code, classes shall be adapted for new model checkpoints, while there are some exceptions where it is preferred to add new classes to make sure the code is kept concise and
92
+
- The model design is a difficult trade-off between keeping code readable and concise and supporting many model checkpoints. For most parts of the modeling code, classes shall be adapted for new model checkpoints, while there are some exceptions where it is preferred to add new classes to make sure the code is kept concise and
93
93
readable longterm, such as [UNet blocks](https://github.com/huggingface/diffusers/blob/main/src/diffusers/models/unet_2d_blocks.py) and [Attention processors](https://github.com/huggingface/diffusers/blob/main/src/diffusers/models/cross_attention.py).
94
94
95
95
### Schedulers
96
96
97
97
Schedulers are responsible to guide the denoising process for inference as well as to define a noise schedule for training. They are designed as individual classes with loadable configuration files and strongly follow the **single-file policy**.
98
98
99
99
The following design principles are followed:
100
-
- All schedulers are found in [`src/diffusers/schedulers`](https://github.com/huggingface/diffusers/tree/main/src/diffusers/schedulers).
101
-
- Schedulers are **not** allowed to import from large utils files and shall be kept very self-contained.
102
-
- One scheduler python file corresponds to one scheduler algorithm (as might be defined in a paper).
100
+
- All schedulers are found in [`src/diffusers/schedulers`](https://github.com/huggingface/diffusers/tree/main/src/diffusers/schedulers).
101
+
- Schedulers are **not** allowed to import from large utils files and shall be kept very self-contained.
102
+
- One scheduler python file corresponds to one scheduler algorithm (as might be defined in a paper).
103
103
- If schedulers share similar functionalities, we can make use of the `#Copied from` mechanism.
104
104
- Schedulers all inherit from `SchedulerMixin` and `ConfigMixin`.
105
105
- Schedulers can be easily swapped out with the [`ConfigMixin.from_config`](https://huggingface.co/docs/diffusers/main/en/api/configuration#diffusers.ConfigMixin.from_config) method as explained in detail [here](./using-diffusers/schedulers.mdx).
Copy file name to clipboardexpand all lines: README.md
+9-9
Original file line number
Diff line number
Diff line change
@@ -30,7 +30,7 @@ We recommend installing 🤗 Diffusers in a virtual environment from PyPi or Con
30
30
### PyTorch
31
31
32
32
With `pip` (official package):
33
-
33
+
34
34
```bash
35
35
pip install --upgrade diffusers[torch]
36
36
```
@@ -107,7 +107,7 @@ Check out the [Quickstart](https://huggingface.co/docs/diffusers/quicktour) to l
107
107
|[Training](https://huggingface.co/docs/diffusers/training/overview)| Guides for how to train a diffusion model for different tasks with different training techniques. |
108
108
## Contribution
109
109
110
-
We ❤️ contributions from the open-source community!
110
+
We ❤️ contributions from the open-source community!
111
111
If you want to contribute to this library, please check out our [Contribution guide](https://github.com/huggingface/diffusers/blob/main/CONTRIBUTING.md).
112
112
You can look out for [issues](https://github.com/huggingface/diffusers/issues) you'd like to tackle to contribute to the library.
113
113
- See [Good first issues](https://github.com/huggingface/diffusers/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) for general opportunities to contribute
image = pipe("A picture of a sks dog in a bucket", num_inference_steps=25).images[0]
261
261
```
262
262
263
+
<Tip>
264
+
265
+
If your LoRA parameters involve the UNet as well as the Text Encoder, then passing
266
+
`cross_attention_kwargs={"scale": 0.5}` will apply the `scale` value to both the UNet
267
+
and the Text Encoder.
268
+
269
+
</Tip>
270
+
263
271
Note that the use of [`~diffusers.loaders.LoraLoaderMixin.load_lora_weights`] is preferred to [`~diffusers.loaders.UNet2DConditionLoadersMixin.load_attn_procs`] for loading LoRA parameters. This is because
264
272
[`~diffusers.loaders.LoraLoaderMixin.load_lora_weights`] can handle the following situations:
"`use_safetensors`=True but safetensors is not installed. Please install safetensors with `pip install safetenstors"
@@ -953,6 +956,12 @@ def load_lora_weights(self, pretrained_model_name_or_path_or_dict: Union[str, Di
953
956
warn_message="You have saved the LoRA weights using the old format. To convert the old LoRA weights to the new format, you can first load them in a dictionary and then create a new dictionary like the following: `new_state_dict = {f'unet'.{module_name}: params for module_name, params in old_state_dict.items()}`."
954
957
warnings.warn(warn_message)
955
958
959
+
@property
960
+
deflora_scale(self) ->float:
961
+
# property function that returns the lora scale which can be set at run time by the pipeline.
Copy file name to clipboardexpand all lines: src/diffusers/pipelines/alt_diffusion/pipeline_alt_diffusion.py
+14-2
Original file line number
Diff line number
Diff line change
@@ -24,7 +24,7 @@
24
24
25
25
from ...configuration_utilsimportFrozenDict
26
26
from ...image_processorimportVaeImageProcessor
27
-
from ...loadersimportTextualInversionLoaderMixin
27
+
from ...loadersimportLoraLoaderMixin, TextualInversionLoaderMixin
28
28
from ...modelsimportAutoencoderKL, UNet2DConditionModel
29
29
from ...schedulersimportKarrasDiffusionSchedulers
30
30
from ...utilsimportdeprecate, logging, randn_tensor, replace_example_docstring
@@ -52,7 +52,7 @@
52
52
53
53
54
54
# Copied from diffusers.pipelines.stable_diffusion.pipeline_stable_diffusion.StableDiffusionPipeline with Stable->Alt, CLIPTextModel->RobertaSeriesModelWithTransformation, CLIPTokenizer->XLMRobertaTokenizer, AltDiffusionSafetyChecker->StableDiffusionSafetyChecker
0 commit comments