Open flux627 opened 10 months ago
I decided to test this on my machine. i5-7600k, Win11, GPU RTX 4060 ti 16 GB and for me the images that appear are in accordance to the uploaded ones on penultimate side when I activate this option. Are you certain you managed to get it activated when testing?
"Another note is that I thought maybe the option named "Always discard next-to-last sigma" was related to this issue, and while it does produce images without this problem, the images are entirely different."
In addition the issue was only present on this checkpoint which from what I know is only fine tuned on 512x512 images yet you sample at 768x768.
I'm not sure what happened before, but now this seems to work.
While this is great news, I wonder if this is an acceptable solution. Why would this option need to be turned on for them to function properly? Is there a reason why these schedulers don't already do what this option does to fix them? Would they at least benefit from some indication that they only work with this special, hidden, non-obvious option?
In addition the issue was only present on this checkpoint which from what I know is only fine tuned on 512x512 images yet you sample at 768x768.
I simplified for reproduction, but this was happening on all other checkpoints I was trying it on as well. I was using Hires fix, which indeed runs an img2img diffusion process at 768x768. If this bug only happens when generating on a mismatched resolution, it is still a bug. Generating at arbitrary resolutions should be supported. (I think this is upheld implicitly by virtue of how hires fix works.)
For what it's worth- I just tried it, and I'm still getting the same problem when generating 512x512 images:
DPM++ 2M SDE: | Penultimate | Final |
---|---|---|
Is there an existing issue for this?
What happened?
I was showing/explaining to some friends how the diffusion process works recently, which led me to configure webui to always show full quality preview images at a very fast interval (essentially showing me all steps as they are processed). I ended up kind of enjoying this (even if generations take longer) and left it on.
I started noticing that for some scheduler types, the result would converge with mostly minor adjustments for the last 30% of the steps, however when the final image was revealed, it looked terrible suddenly. Immediately, I thought this must have been a VAE-switch issue (where the previews were using a different VAE than the final conversion) but I verified this not the case- regardless of VAE being used, this happens.
After going through all schedulers, I have isolated the issue to the following schedulers (roughly ordered from most severe to least). All images are generated with this prompt + configuration:
Another note is that I thought maybe the option named "Always discard next-to-last sigma" was related to this issue, and while it does produce images without this problem, the images are entirely different.
Steps to reproduce the problem
I'm running on an M1 Macbook Pro. See image generation configuration above.
What should have happened?
It seems there might be an extra process that may or not be intentional that is changing the image in an unfavorable way at the very end with these schedulers. If it is intentional, there should be an option to either toggle its effects, or change its intensity.
Sysinfo
What browsers do you use to access the UI ?
Google Chrome
Console logs
Additional information
No response