@@ -60,17 +60,17 @@ Let's walk through more in-detail design decisions for each class.
60
60
61
61
### Pipelines
62
62
63
- Pipelines are designed to be easy to use (therefore do not follow [*Simple over easy*](#simple-over-easy) 100%)) , are not feature complete, and should loosely be seen as examples of how to use [models](#models) and [schedulers](#schedulers) for inference.
63
+ Pipelines are designed to be easy to use (therefore do not follow [*Simple over easy*](#simple-over-easy) 100%), are not feature complete, and should loosely be seen as examples of how to use [models](#models) and [schedulers](#schedulers) for inference.
64
64
65
65
The following design principles are followed:
66
66
- Pipelines follow the single-file policy. All pipelines can be found in individual directories under src/diffusers/pipelines. One pipeline folder corresponds to one diffusion paper/project/release. Multiple pipeline files can be gathered in one pipeline folder, as it’s done for [`src/diffusers/pipelines/stable-diffusion`](https://github.com/huggingface/diffusers/tree/main/src/diffusers/pipelines/stable_diffusion). If pipelines share similar functionality, one can make use of the [#Copied from mechanism](https://github.com/huggingface/diffusers/blob/125d783076e5bd9785beb05367a2d2566843a271/src/diffusers/pipelines/stable_diffusion/pipeline_stable_diffusion_img2img.py#L251).
67
- - Pipelines all inherit from [`DiffusionPipeline`]
67
+ - Pipelines all inherit from [`DiffusionPipeline`].
68
68
- Every pipeline consists of different model and scheduler components, that are documented in the [`model_index.json` file](https://huggingface.co/runwayml/stable-diffusion-v1-5/blob/main/model_index.json), are accessible under the same name as attributes of the pipeline and can be shared between pipelines with [`DiffusionPipeline.components`](https://huggingface.co/docs/diffusers/main/en/api/diffusion_pipeline#diffusers.DiffusionPipeline.components) function.
69
69
- Every pipeline should be loadable via the [`DiffusionPipeline.from_pretrained`](https://huggingface.co/docs/diffusers/main/en/api/diffusion_pipeline#diffusers.DiffusionPipeline.from_pretrained) function.
70
70
- Pipelines should be used **only** for inference.
71
71
- Pipelines should be very readable, self-explanatory, and easy to tweak.
72
72
- Pipelines should be designed to build on top of each other and be easy to integrate into higher-level APIs.
73
- - Pipelines are **not** intended to be feature-complete user interfaces. For future complete user interfaces one should rather have a look at [InvokeAI](https://github.com/invoke-ai/InvokeAI), [Diffuzers](https://github.com/abhishekkrthakur/diffuzers), and [lama-cleaner](https://github.com/Sanster/lama-cleaner)
73
+ - Pipelines are **not** intended to be feature-complete user interfaces. For future complete user interfaces one should rather have a look at [InvokeAI](https://github.com/invoke-ai/InvokeAI), [Diffuzers](https://github.com/abhishekkrthakur/diffuzers), and [lama-cleaner](https://github.com/Sanster/lama-cleaner).
74
74
- Every pipeline should have one and only one way to run it via a `__call__` method. The naming of the `__call__` arguments should be shared across all pipelines.
75
75
- Pipelines should be named after the task they are intended to solve.
76
76
- In almost all cases, novel diffusion pipelines shall be implemented in a new pipeline folder/file.
@@ -104,7 +104,7 @@ The following design principles are followed:
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).
106
106
- Every scheduler has to have a `set_num_inference_steps`, and a `step` function. `set_num_inference_steps(...)` has to be called before every denoising process, *i.e.* before `step(...)` is called.
107
- - Every scheduler exposes the timesteps to be " looped over" via a `timesteps` attribute, which is an array of timesteps the model will be called upon
107
+ - Every scheduler exposes the timesteps to be " looped over" via a `timesteps` attribute, which is an array of timesteps the model will be called upon.
108
108
- The `step(...)` function takes a predicted model output and the " current" sample (x_t) and returns the " previous" , slightly more denoised sample (x_t-1).
109
109
- Given the complexity of diffusion schedulers, the `step` function does not expose all the complexity and can be a bit of a " black box" .
110
110
- In almost all cases, novel schedulers shall be implemented in a new scheduling file.
0 commit comments