Gilbert Stuart never finished this one. The head carries every decision he made, the rest carries almost none. Denoising strength is the dial that decides which parts of your input end up on which side of that line.
Gilbert Stuart never finished this one. The head carries every decision he made, the rest carries almost none. Denoising strength is the dial that decides which parts of your input end up on which side of that line.
It is not an opacity slider. It picks a starting point on the noise schedule, and it silently sets your real step count too.
You drop a photo into img2img, leave the denoising strength where it was, type a prompt, and get back a picture that has the same general colours and none of the same face. Then you nudge the number down to 0.3 and get back something that looks like your photo run through a bad phone filter, soft in a way that reads as cheap. Neither result is what you asked for, and the slider gives you no clue why.
The default in the most widely used interface is 0.75. That single number is doing two completely different jobs at once, and almost nobody is told about the second one.
The technique underneath img2img was published in 2021 as SDEdit, by Chenlin Meng, Yutong He, Yang Song, Jiaming Song, Jiajun Wu, Jun-Yan Zhu and Stefano Ermon. The paper's description of the method is three clauses long and worth memorising: given an input image, it first adds noise to the input, then denoises the result through the model's prior to increase its realism.
That is the whole mechanism. Your picture does not get blended with a generated picture. Your picture gets wrecked, on purpose, by a controlled amount of noise, and then the model is asked to clean up the mess. Whatever survives the wrecking is what you keep.
Denoising strength is how hard you wreck it. The paper is explicit that this quantity is the knob balancing realism against faithfulness to the input, and that pushing it up buys deviation from your image while pushing it down buys fidelity to it. There is no third option in there. You are always trading one for the other.
So a value of 0.75 does not mean 25 percent of your photo remains visible in some blended sense. It means the process starts three quarters of the way up the noise ladder, where a photograph is mostly a field of static with a faint bias in it. Broad layout and colour distribution survive that. A specific nose does not.
Here is the part that explains the mushy low-denoise results. In the default configuration of the AUTOMATIC1111 web UI, the code that sets up an img2img run reads like this:
steps = p.steps
t_enc = int(min(p.denoising_strength, 0.999) * steps)
Read the second line slowly. t_enc is how many denoising steps actually execute. It is your step count multiplied by your denoising strength, rounded down. The number in the steps box is not the number of steps you get.
Set 20 steps and denoise 0.2, and you run four steps. Four. Set 20 and 0.1 and you run two. Set 20 and 0.3 and you run six. That soft, undercooked look people blame on the model or the sampler at low denoise is frequently just a two-step or four-step generation, which is exactly what a two-step generation looks like.
The arithmetic at 20 steps: 0.10 gives you 2 real steps. 0.20 gives 4. 0.30 gives 6. 0.40 gives 8. 0.50 gives 10. 0.75 gives 15. And 1.00 gives 19, not 20, because of a clamp we will get to.
There is an option, usually labelled something like "with img2img, do exactly the amount of steps the slider specifies," and turning it on flips the arithmetic completely:
steps = int(requested_steps / min(p.denoising_strength, 0.999))
t_enc = requested_steps - 1
Now the interface builds a longer schedule so that the slice you run is the length you asked for. Request 20 steps at denoise 0.25 and it constructs an 80-step schedule and runs the top 20 of it. At 0.5 it builds 40. At 0.75 it builds 26. At 1.0 it builds 20 and runs 19.
Both behaviours are defensible. The default keeps a low-denoise pass fast, which matters when you are running a refinement on top of a first render and you genuinely only want a light touch. The option gives you a consistent, comparable step count across every value, which matters when you are trying to isolate what the denoise number alone is doing. What is not defensible is not knowing which one your setup is using, because the same denoise value produces different quality under each.
Both branches wrap the value in min(p.denoising_strength, 0.999). You cannot actually reach 1.0 through that code path. Push the slider to the top and the clamp quietly holds it one thousandth short.
The practical consequence is small but real. There is always a sliver of your input left in the result, and at 20 steps that clamp is also why the top of the slider gives you 19 executed steps rather than 20. If you truly want a generation with no memory of the input, you want text to image, not img2img at maximum.
Stop thinking about it as a percentage of the picture and start thinking about it as a question: what is the largest thing in this image that I am willing to lose?
If the answer is "surface texture only, keep the pose and the face exactly," you want a low value, and you want the fixed-steps option on so that low value does not also hand you a four-step render. If the answer is "keep the composition, replace the subject," you are in the middle of the range, where layout survives and identity does not. If the answer is "keep the colour mood and nothing else," you are near the top, and you should ask yourself honestly whether a text prompt with a colour description would get you there with less fuss.
The one test worth running takes five minutes. Fix the seed. Fix the prompt. Generate the same input at 0.2, 0.4, 0.6 and 0.8, and put the four side by side. You will see the exact point where your subject stops being your subject, and that point moves depending on the model, the resolution, and how much detail was in the input to begin with. It is not the same number for a tight portrait and a wide landscape, and no guide can hand it to you.
Low denoise is not automatically the safe choice. If the thing wrong with your input is structural, a bad hand, a broken perspective line, a limb that goes nowhere, then a low value faithfully preserves the problem and adds a light coat of paint over it. Those cases need a high value, or they need inpainting on the specific region, or they need a fresh generation. Turning the number down when the composition is the fault is how people end up with twelve slightly different versions of the same broken hand.
And the whole framing changes when img2img is being used as a refinement stage after an upscale rather than as an editing tool. In that context the input is not a photograph you are protecting, it is a stretched render you are trying to add real detail back into, and the useful values sit low for a completely different reason: you are not preserving a subject, you are avoiding the model inventing a second face in the corner of a tile.
What stays constant across all of it is the mechanism. Noise goes in, the model cleans it out, and the number decides how much noise and, unless you have said otherwise, how much cleaning. Everything else is taste.