stable-diffusion VS diffusers

Which is a 1-click install of Stable Diffusion with an alternative web interface. You can choose a different approach but this one is pretty simple and I am new to this stuff.

an invisible watermarking of the outputs, to help viewers identify the images as machine-generated.

It sounds like you just want to set up Stable Diffusion to run locally. I don't think your computer's specs will be able to do it. You need a graphics card with a decent amount of VRAM. Stable diffusion is in Python as is almost every AI open source project I've seen. If you can get your hands on a system with an Nvidia RTX card with as much VRAM as possible, you're in business. I have an RTX 3060 with 12 gigs of VRAM and I can run stable diffusion and a whole variety of open source LLMs as well as other projects like face swap, Roop, tortoise TTS, sadtalker, etc...

Use specific GPU on multi GPU systems · Issue #87 · CompVis/stable-diffusion · GitHub

I dealt with this in one of my posts. At least SD 1.1 till 1.5 are all trained on a batch size of 2048. The version pretty much everyone uses (1.5) is first pretrained at a resolution of 256x256 for 237K steps on laion2B-en, at the end of those training steps it will have seen roughly 500M images in laion2B-en. After that it is pre-trained for 194K steps on laion-high-resolution at a resolution of 512x512, which is a subset of 170M images from laion5B. Finally it is trained for 1.110K steps on LAION aesthetic v2 5+. This is easily verified by taking a glance at the model card of SD 1.5. Though that one doesn't specify for part of the training exactly which aesthetic set was used for part of the training, for that you have to look at the CompVis github repo. Thus at the end of it all both the most recent images and the majority of images will have come from LAION aesthetic v2 5+ (seeing every image approx 4 times). Realistically a lot of the weights obtained from pretraining on 2B will have been lost, and only provided a good starting point for the weights.

stable diffusion · CompVis/stable-diffusion@2ff270f · GitHub

Here for example --> https://github.com/CompVis/stable-diffusion

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