Repository: AUTOMATIC1111/stable-diffusion-webui

Issue:
[Bug]: gens from same seed/params/model permanently changed
### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What happened?

the gens for any given seed/parameter no longer match the original gen

 This has been recurring for me over the last week or so without any clear cause or explanation.  Only solution is a clean reclone of the complete repo, at which point it properly gens again for a while, then does it again.

The two images below are generated from the exact same seed, parameters, model, run about two minutes apart.   Important to note that if I do a clean re-install and run the gen again, it will come out identical to the first instance, and once something happens it always comes out identical to the second instance. Further, I have instances of the first gen that go back at least six weeks, so I would call that the "correct" gen for that seed/model/prompt.

Once the generations are modified, the only solution I've found that works is to completely wipe the install, do a clean git clone of the repo and restart.  Afterwards the problem can come back as quickly as two gens or not for some time,





### Steps to reproduce the problem

1. install A1111 and set the model to F111 [or whatever other model]
2. Load an image into png info, select send to text to image, and gen an image
3.  continue changing models and input images for 2-X events
4. Intermittently check the original gen/model combo



### What should have happened?

Every time the model, seed, prompt and gradio settings are the same, the gen /output should remain the same, over time.


### Commit where the problem happens

98947d173e3f1667eba29c904f681047dea9de90

### What platforms do you use to access UI ?

Windows

### What browsers do you use to access the UI ?

Mozilla Firefox

### Command Line Arguments

```Shell
none
```


### Additional information, context and logs

The issue doesn't seem to be associated with a specific model, although F111 is the one I've had enough history on to have a baseline image to compare it for the longest.  Once the switch happens, all models have their outputs changed.

I've reviewed most or all of the files and directories in the a111 distro to see which ones have been revised pre-post the symptom, but only params and config seem to be materially revised.







Discussion:
Just noticed this exact same thing happening to me as well. Also did a new clone, it worked fine for a bit but then it started happening again.
OK I've identified the cause and can correct the issue manually, but it still feels like a bug.  This appears to result from clip skip > 1 being "inherited" by subsequent gens from a seed that may not have had a clip skip in its original prompt.  Forcing clipskip =1 in settings results in the image gen correctly matching the legacy input seed/params.   To replicate the issue:

1. Load an image whose png info does not include clipskip. Generate should match the original. Reviewing the params.txt file, there is no "clip skip" parameter 
2. Load a different  image whose png info includes clipskip =2 . Generate.  Review the params file. it will now show clipskip 2, despite the source image png info being default/none or 1( when I  switch between clip skip 1 and 2 in settings, I get the same set of results - 1 = matches original exactly, 2= different from original, but always the same)
4. reload the 1st image without the clipskip info and generate.  Review the parameters in both settings and the params.txt file - the clip skip for the original image will now be 2.

This feels like it's still a bug because the _global_ clip_ skip value in the settings menu is being reset to whatever the png info tells it to (rather than just rendering that specific instance with clip skip value specific to that image parameter.   
Would it be possible for png-modified clip-skips only to be passed to that rendering argument, rather than modifying clip skip for _all_ gens?

It's additionally worth noting that a **brand new image gen** (as of this commit anyways) that has clip skip 1 does not retain ANY clip skip info, so while > 1 re-writes the global clipskip setting to whatever that is, a clipskip 1 image will not do so. So any clipskip 1's require manually updating the global setting every time.





> OK I've identified the cause and can correct the issue manually, but it still feels like a bug. This appears to result from clip skip > 1 being "inherited" by subsequent gens from a seed that may not have had a clip skip in its original prompt. Forcing clipskip =1 in settings results in the image gen correctly matching the legacy input seed/params. To replicate the issue:
> 
> 1. Load an image whose png info does not include clipskip. Generate should match the original. Reviewing the params.txt file, there is no "clip skip" parameter
> 2. Load a different  image whose png info includes clipskip =2 . Generate.  Review the params file. it will now show clipskip 2, despite the source image png info being default/none or 1( when I  switch between clip skip 1 and 2 in settings, I get the same set of results - 1 = matches original exactly, 2= different from original, but always the same)
> 3. reload the 1st image without the clipskip info and generate.  Review the parameters in both settings and the params.txt file - the clip skip for the original image will now be 2.
> 
> This feels like it's still a bug because the _global_ clip_ skip value in the settings menu is being reset to whatever the png info tells it to (rather than just rendering that specific instance with clip skip value specific to that image parameter. Would it be possible for png-modified clip-skips only to be passed to that rendering argument, rather than modifying clip skip for _all_ gens?
> 
> It's additionally worth noting that a **brand new image gen** (as of this commit anyways) that has clip skip 1 does not retain ANY clip skip info, so while > 1 re-writes the global clipskip setting to whatever that is, a clipskip 1 image will not do so. So any clipskip 1's require manually updating the global setting every time.

This was very useful and solved the problem for me too. Thanks!
> clip skip 1 does not retain ANY clip skip info

I saw an issue here (but I cannot find it now) which proposed these changes:
1. Always output clipskip to meta-info.
2. Treat non-existing clipskip in meta-info as "1".

Looks like both are need to be implemented, otherwise the issues like this will be countless!
Ran across the same issue, I was scratching my head about how my seeds could have been changed, but it turns out I had a non-zero clip-skip that wasn't being overridden by the prompt missing a `Clip skip` entry

Resolving patch:
diff --git a/modules/generation_parameters_copypaste.py b/modules/generation_parameters_copypaste.py
--- a/modules/generation_parameters_copypaste.py
+++ b/modules/generation_parameters_copypaste.py
@@ -184,6 +184,10 @@ def parse_generation_parameters(x: str):
         else:
             res[k] = v
 
+    # Missing CLIP skip means it was set to 1 (the default)
+    if "Clip skip" not in res:
+        res["Clip skip"] = "1"
+
     return res
 
 
diff --git a/modules/shared.py b/modules/shared.py
--- a/modules/shared.py
+++ b/modules/shared.py
@@ -371,7 +371,7 @@ def list_samplers():
     "enable_batch_seeds": OptionInfo(True, "Make K-diffusion samplers produce same images in a batch as when making a single image"),
     "comma_padding_backtrack": OptionInfo(20, "Increase coherency by padding from the last comma within n tokens when using more than 75 tokens", gr.Slider, {"minimum": 0, "maximum": 74, "step": 1 }),
     "filter_nsfw": OptionInfo(False, "Filter NSFW content"),
-    'CLIP_stop_at_last_layers': OptionInfo(1, "Stop At last layers of CLIP model", gr.Slider, {"minimum": 1, "maximum": 12, "step": 1}),
+    'CLIP_stop_at_last_layers': OptionInfo(1, "Stop at last layers of CLIP model (CLIP skip)", gr.Slider, {"minimum": 1, "maximum": 12, "step": 1}),
     "random_artist_categories": OptionInfo([], "Allowed categories for random artists selection when using the Roll button", gr.CheckboxGroup, {"choices": artist_db.categories()}),
 }))
 


Test patch: