unpaint VS diffusers

Here are the details: Running Unpaint on the Xbox Series consoles · axodox/unpaint Wiki (github.com)

I also started to build an app of my own on top of it called Unpaint (which you can download and try following the link), targeting Windows and (for now) DirectML. The app provides the basic Stable Diffusion pipelines - it can do txt2img, img2img and inpainting, it also implements some advanced prompting features (attention, scheduling) and the safety checker. It is lightweight and starts up quickly, and it is just ~2.5GB with a model, so you can easily put it on your fastest drive. Performance wise with single images is on par for me with CUDA and Automatic1111 with a 3080 Ti, but it seems to use more VRAM at higher batch counts, however this is a good start in my opinion. It also has an integrated model manager powered by Hugging Face - though for now I restricted it to avoid vandalism, however you can still convert existing models and install them offline (I will make a guide soon). And as you can see on the above images: it also has a simple but nice user interface.

The source code is on GitHub (here: axodox/native-diffusion (github.com)), there is also an installer in releases, if you want to try it.

I made a C++ test project here: Release Olive Test · axodox/native-diffusion (github.com)

Well, I am working on a port of StableDiffusion which uses C++ only, no python, no other dependencies and crap. I have txt2img, img2img and inpainting fully working now.

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