sd-webui-controlnet
sd-webui-controlnet copied to clipboard
[bug?] Extreme color variations in txt2img
sd-webui-controlnet: latest commit at the time of writing
I encountered a strange problem today. When using the hed, canny, or scribble, the resulting image will have too saturated colors. It depends on "weight" slider, i.e. the smaller the value, the colors more correct. No difference between control_sd15_ and difference_controlsd15 models. Effect is extremely noticeable on realistic models, less - on anime models. Example:
Original image (in ControlNet):
heg, weight 1:
heg, weight 0.6:
heg, weight 0.3:
heg, weight 0.1
Any ideas, how to fix it?
Fixed by enabling "Only use mid-control when inference" option. I honestly don't know, what it does, but it's work.
I tried whit this option, but now it is absolutely different to the photo. I have the same problem.
Fixed by enabling "Only use mid-control when inference" option. I honestly don't know, what it does, but it's work.
sd-webui-controlnet: latest commit at the time of writing I encountered a strange problem today. When using the hed, canny, or scribble, the resulting image will have too saturated colors. It depends on "weight" slider, i.e. the smaller the value, the colors more correct. No difference between control_sd15_ and difference_controlsd15 models. Effect is extremely noticeable on realistic models, less - on anime models. Example: Original image (in ControlNet):
heg, weight 1:
heg, weight 0.6:
heg, weight 0.3:
heg, weight 0.1
Any ideas, how to fix it?
I have exactly the same problem. “Only use mid-control when inference” deactivate ControlNet or at least Multi ControlNet. The image is absolutely different.
All my Controlnet images are full saturated and yellow using realistic models. Why? Somebody fixed it?
After a lot of work I saw that the problem was HED. I don't know why it takes the color of the input image and force to the final output.
As I see is a BUG
People in general has this problem as we can see in this article: https://stable-diffusion-art.com/controlnet/#HED
Hope they can fix it.
Any updates on this? Still having the same issues here.
Tested with hed: all results are reproducible in the original controlnet repo and this extension. That means if there is a color shift in the result, it is more likely due to some bias in the original model.
Base | Extension |
---|---|
![]() |
![]() |
Any update on this? Still have this problem
Any update on this? Still have this prob
Do you have Microsoft Visual Studio installed on your system? I did a whole bunch of uninstalling/resinstalling/etc for basically 10hrs a few days ago and I'm pretty in my case the issue was related to Visual Studio. If you did install that previously, try uninstalling it completely and reinstalling it. Then if you have CUDA 11.8 or 12 installed try also uninstalling those and reinstalling them (11.8 is the supported version at the moment).
It's also possible another extension broke something so I removed everything, re-cloned A1111 and started over. I'd tried that first but it didn't fix the problem - so I not 100% sure. If it helps these are the extensions I tended to install even if I used them rarely:
ControlNet Dynamic Prompts Auto-complete 3-D openpose Open pose Remove Background Ultimate Upscale Dynamic Thresholding System Information (this one was the newest I'd installed)
I cut it back to just 3 or 4 essentials for me (CN, Dynamic, Autocomplete, and Dynamic thresholding)
I'd tried other extensions also but generally deleted them fairly quick. Didn't expect problems (and maybe it wasn't them - dunno). There was also a few times w/ A1111 where I checkedout previous versions (commits) and then later returned to the master branch. Reinstalling completely as I did early on I'd expect would have resolved that if it was the fundamental cause, but maybe not....
Good luck!
Good luck!
I dont think it's due to visual studio since I run stable difussion through google colab, but I'll try disabling extensions, other than controlnet I think I only have ultimate sd upscaler and some aspect ratio helper, I'll delete them and see if it helps, thank you
Try and disable "Apply color correction to img2img results to match original colors.", under settings/Stable Diffusion
This fixed my issues, it might affect consistency when iterating though
So, still no fix?
So, still no fix?
I think it might be a problem with the controlnet code or the hed annotator code, 'cause I checked the Feb 26 hed and the Feb 17 hed, they both give the same burned result.
Upd: also, it seems that this bug starts, when the hed resolution is increased from 512 to 1024
HED 512 ^
HED 1024 ^
so, are some people not getting this bug? this makes it pretty unusable, so it is probally not everyone or this issue would be filled with people reporting this.. so maybe its a enviroment thing?
so, are some people not getting this bug? this makes it pretty unusable, so it is probally not everyone or this issue would be filled with people reporting this.. so maybe its a enviroment thing?
I've noticed lately that I only have this bug showing up in txt2img, and img2img is fine.
Interesting, I only get in img2img, and its not always (but almost always)
For reference, this problem is solved in CN 1.1. The reason is that the training data of 1.0 has several problems and this image trigged the problem.
Below is results from CN 1.0 (i can reproduce the artifacts)
Below is results from CN 1.1 (problem is solved)
The image use the same meta data input with the original image in this post.
Same. Did you find out any way to fix it?
Bug still exists for me, on CN 1.1.227
I started to have this bug on the XL controlnet. I had something similar on a completely unrelated project, after the update on the Community VS. When some certain MSVC library updated broken in FVectors. Instead of the normalized space, they went exponential. So I guess it is may be probably related to some low level library of some sort here as well. But I'm not even sure how to debug it for the Automatic1111. Is anyone is still having this bug yet?