stable-diffusion VS diffusers

SD on an Intel mac with Vega graphics runs pretty well though — I think it ran at something like ~3-5 iterations/s for me, which is decent. I ran either https://github.com/magnusviri/stable-diffusion or https://github.com/lstein/stable-diffusion which have MPS support

https://github.com/magnusviri/stable-diffusion/commit/d0b168...

Copying this change fixed seeds on M1 for me.

You should be able to run it on a CPU. Maybe try this version. If MPS is supported on your Mac you can check this out.

A group of open source hackers forked Stable Diffusion on GitHub and optimized the model to run on Apple's M1 chip, enabling images to be generated in ~ 15 seconds (512x512 pixels, 50 diffusion steps).

Magnusviro [0], the original author of the SD M1 repo credited in this article, has merged his fork into the Lstein Stable Diffusion repo [1], and you can now run Lstein fork with M1 as of a few hours ago.

This adds a ton of functionality - GUI, Upscaling & Facial improvements, weighted subprompts etc.

This has been a big undertaking over the last few days, and I highly recommend checking it out.

[0] https://github.com/magnusviri/stable-diffusion

You can run it on an M1. Using a macbook M1 pro max with 32Gb I get 512x512 in about 50 seconds. use this branch https://github.com/magnusviri/stable-diffusion/tree/apple-mps-support

I had this error too, and I tried a ton of things to get cudatoolkit to install, without any luck. This fork has an environment-mac.yml file that actually got it working on my M1 Max: https://github.com/magnusviri/stable-diffusion/tree/apple-silicon-mps-support

But when I run it (locally, using the Mac M1 port), every time I run it creates a different image.

I'm missing something about the random factor, from the sample code from https://github.com/huggingface/diffusers/blob/main/README.md

Hey people, I noticed that combining these two methods in a single forward pass increases the controllability of the generation quite a bit. I was kind of puzzled that sometimes ControlNet yielded better results than T2IAdapter for some cases, and sometimes it was the other way around, so I decided to test both at the same time, and results were quite nice. Some visuals and more motivation here: https://github.com/huggingface/diffusers/issues/5847 And it was already merged here: https://github.com/huggingface/diffusers/pull/5869

Open Parti Prompts: The better way to evaluate diffusion models (repo)

You have disabled the safety checker for by passing `safety_checker=None`. Ensure that you abide to the conditions of the Stable Diffusion license and do not expose unfiltered results in services or applications open to the public. Both the diffusers team and Hugging Face strongly recommend to keep the safety filter enabled in all public facing circumstances, disabling it only for use-cases that involve analyzing network behavior or auditing its results. For more information, please have a look at https://github.com/huggingface/diffusers/pull/254 .

For developers, TensorRT support also exists for the diffusers library via community pipelines. [1] It's limited, but if you're only supporting a subset of features, it can help.

In general, these insane speed boosts comes at the cost of bleeding edge features.

[1] https://github.com/huggingface/diffusers/blob/28e8d1f6ec82a6...

I was training sdxl UNET base model, with the diffusers library, which was going great until around step 210k when the weights suddenly turned back to their original values and stayed that way. I also tried with the ema version, which didn't change at all. I also looked at the tensor's weight values directly which confirmed my suspicions.

Merging LoRAs is essentially taking a weighted average of the LoRA adapter weights. It's more common in other UIs.

diffusers is working on a PR for it: https://github.com/huggingface/diffusers/pull/4473