Spaces:
Runtime error
Can't Replicate Images from this Space?
I've tried to replicate the images that I get from this space using Automatic1111 (windows) and the AnythingV3 model (both pruned and the 7.7GB version) and no matter what I do the images that I get are very different from the ones produced here. Even with the same Seed, CFG Scale, Steps, Resolution, Prompts etc. I've even done tests using Clip skip on 1,2 and 3, as well as HiresFix on and off (still matching the resolution) with results that don't match this space in the slightest. I've also done tests using the various DPM++ Samplers and none of the ones available on Automatic1111 seem to come close.
Are there any hidden settings that this space is using on the AnythingV3 model that are causing it to produce images that differ from my Local version? Is it even possible to match the configuration found here using Automatic1111?
Please let me know because I like the images this space produces and I'd like to replicate it on my local hardware.
Hi,
There are two main reasons I can think of:
- The models you are using are different
- The A1111 implementation of DPM-Solver is different from the one used in this app (
DPMSolverMultistepSchedulerfrom thediffuserslibrary).
(3. Or maybe there's some postprocessing in A1111, I'm not familiat with it.)
@anzorq :
The issue is definitely not caused by this app itself.
I had the same issue when testing Epic Diffusion on multiple platforms. I was unable to produce the same images on the A1111 GUI that I was able to produce with a simple diffusers script, regardless of which scheduler I used. Results were "very different" indeed.
It is indeed very likely the A1111 implementation of DPM-Solver is different from the one used by diffusers. Either that, or it has something to do with the way the A1111 GUI interprets the prompt. This GUI does not have the same 77 token restriction the diffusers library has, so it does seem to interpret the prompt in a different way. This could also have an impact on the output.
Maybe someone like @patrickvonplaten can comment on this? He's part of the Huggingfaces technical team and actually involved in the development of the diffusers library that's used in this demo to do the hard work (including the schedulers). He may know more about this...
THe DPM-Solver of A1111 is indeed a bit different from the solver implemented in diffusers, see: https://github.com/crowsonkb/k-diffusion/discussions/48 . K-Diffusion uses slightly different timesteps as mentioned in the paper.
However schedulers such as Heun should be 1-to-1 the same.
Also, it might be the case that A1111 sets the seed on CPU instead of GPU.
Is there a "right" or "preferred" way to implement a DPM-Solver?
A1111 seems to have become more or less the default way to use Stable Diffusion for most people. It having a different implementation for what's one of the better schedulers out there is going to confuse a lot of people (including myself), and it might hinder adoption of the diffusers library by Stable Diffusion users because of it.
From an end user perspective, it would be better if either diffusers or the A1111 GUI modify their implementation to make it 1-to-1 with the other, so users can use both interchangeably and get predictable results.