stable-diffusion-webui
stable-diffusion-webui copied to clipboard
AUTOMATIC1111
Add back in Inverse Sigmoid in Checkpoint Merger
I've had much better and linear results using Inverse Sigmoid then Weighted sum. See attached, there is a much more graduallar change using Inverse then Weighted. Weighted only seems to be graduallar between 30% & 70%. Attached is a test I did on the 10th.
I very strongly agree. For two-checkpoint merges, at least, sigmoid can give drastically better merges. I understand 3-ckpt merges may only be possible with weighted sum, but supporting 3-ckpt merges shouldn't come at the expense of smoothstep merges.
Inverse Sigmoid is way better than the other options, I don't know why this option would be removed.
The problem is that they didn't really do much different from mixed sum. Everything at its core did the same thing (mixed sum/lerp), it just messed with your input weight. Let's say you had your input weight at 0.3, using inverse sigmoid would map it to 0.36326... And that would be the exact same as if you just selected mixed sum and put 0.36 as your weight.
If you want to compute the values yourself, and 'emulate' the same effect with mixed sum: Sigmoid: -2x^3 + 3x^2 Inverse sigmoid: 0.5 - sin(arcsin(1 - 2x) / 3) where x is your input weight, gives you the output weight for mixed sum which would be what calling sigmoid and inverse sigmoid respectively would give.
What @hentailord85ez said is accurate, so maybe it's a matter of training the users and adding some explanation in the merge tab. In reality this is just bending the curve at the ends. Notably, a 0.05 mix in linear is only a 0.0073 mix in sigmoid. I think this tapering only feels better for practical use in some cases because a little bit of checkpoint goes a long way at the ends and the slider is chunky.
The fact is that tiny changes in checkpoint weights can have a huge impact on outcomes, so I think it's just subjective whether sigmoid or inverse sigmoid happens to give you a result you prefer. Once you know this, you just know you simply have to try finer step sizes in your merges.
@RnDMonkey i don’t disagree with the theoretic math, but the practical example shows that Inverse is a much evenly gradual change. Inverse is very gradual where weighted is even in the middle, but 20-30 & 80-90 are vast changes much similar to the smooth step and inverse smooth step in your graph
@RnDMonkey there is no "3 checkpoint merging", weighted sum still only uses the first two models, model C is only used to subtract from model B in difference merging. I believe sigmoid was removed bc it was causing confusion with the merge ratio slider.
i also feel the same way could we please have the option to have the sigmoids back on settings perhaps ?
Ultimately, sigmoid gives you more fine control of weighting at the extremes for the slider's 0.05 step size, and inverse sigmoid gives you more fine control of the weighting around the middle, also per slider step. My plan is to just modify my slider step size to 0.005 (10x finer) and try smaller steps at the ends and middle of the range. If I need even finer control, I'll manually enter the multiplier. Sigmoid and inverse sigmoid are just, arguably, subjectively useful abstractions.
Just make it like 0.001 and people will enter the number in the text box.
Just make it like 0.001 and people will enter the number in the text box.
Adding that to ui-config.json would be enough, I think. Then people who want to finetune the numbers can edit it through there, and at the same time, the less technical users could enjoy doing it the default way.
I've just tested dozens of merged models, comparing weighted sum, sigmoid and inversed sigmoid. I can confirm there are sometimes large changes in the output So, I'm also in favor of adding back Sigmoid and Inverse Sigmoid in merging, even if just to allow more "fine control" as @RnDMonkey said it
I've just tested dozens of merged models, comparing weighted sum, sigmoid and inversed sigmoid. I can confirm there are sometimes large changes in the output So, I'm also in favor of adding back Sigmoid and Inverse Sigmoid in merging, even if just to allow more "fine control" as @RnDMonkey said it
Some updates ago it was already implemented in to the ui-config.json file, you can adjust the slider precision to finetune merging to your hearts content.
The line to look for:
"modelmerger/Multiplier (M) - set to 0 to get model A/step": 0.0001,
In my case I adjusted it to 0.0001 precision, thus having finer control on edge cases.
@3dfactor @StewieGriffin @hentailord85ez @RnDMonkey @GhostDragon69
So I did some "fine-tune" test from 0.641 to 0.660 and I get very weird jumps. The first half and the last half are closer to the dreambooth model while the middle section is closer to the prompt minus the dreambooth trigger.
keep in mind there is less than a 2% difference between the first group and last group, why is there a huge jump in the middle? I noticed this in other percentages as well, but this took a while to gather the data, so can't show it all
I found this issue searching for how to change the weight slider values to run a test similar to above. I noticed some weird jumps at .65 that were not happening at .6 and .7.
I also noticed this jump a couple other places too, will do some testing and try to post results if it will help.
It's only a coincidence that the inverse sigmoid in the first example seemed to give smoother results for that prompt and seed. Small changes in parameters can make the process converge to suddenly different results as you cross a threshold, like a ball rolling down a ridge may fall into one basin or the other. Such "jumps" are expected as we adjust parameters, but sometimes we randomly get a transition that looks smoother.
Also, we can't draw good conclusions from an experiment with just one prompt and seed, it would be necessary to repeat the experiment for many different seeds and prompts in order to see what is going on.
I think we could make better plots using img2img with a medium denoising strength, so that the basic form and pose should be similar for all of the images.
It's only a coincidence that the inverse sigmoid in the first example seemed to give smoother results for that prompt and seed. Small changes in parameters can make the process converge to suddenly different results as you cross a threshold, like a ball rolling down a ridge may fall into one basin or the other. Such "jumps" are expected as we adjust parameters, but sometimes we randomly get a transition that looks smoother.
Also, we can't draw good conclusions from an experiment with just one prompt and seed, it would be necessary to repeat the experiment for many different seeds and prompts in order to see what is going on.
I think we could make better plots using img2img with a medium denoising strength, so that the basic form and pose should be similar for all of the images.
I'm not sure if you read all of the comments on here. Many of us were able to reproduce the same results using varying seeds and prompts.
But inverse sigmoid was included back in, so it's moot anyways. A little strange to be commenting on a dead post from a resolved issue...? :)
Does anyone know where to find the file that contains the main checkpoint merge operation?
