Save hires fix images to a different folder?

[CHollman82]

Hi, my workflow involves generating smaller images without hires fix and then doing hires fix on the ones that look good. It would be very useful for my own organization if I could specify a different folder path to save the hires fixed images to. Is this possible? Thanks.

[Woisek]

If this is a separate step and not "in one go", then just simply change the directory to where it should be saved.
And you know, you are just pixel upscale then, and not "highres fix" ... ?

[CHollman82]

I have not found that to be the case, maybe it's something you would notice if you do a checksum or something, but in general if I create two images without changing any of the generation settings I get 2 identical images.

Can you tell me how to put the output directory path as a quick setting? It's better than nothing.

[Woisek]

I have not found that to be the case, maybe it's something you would notice if you do a checksum or something, but in general if I create two images without changing any of the generation settings I get 2 identical images.

If you use a deterministic sampler, then yes, it will be the same. But a checksum won't work, I assume, because it's still a new generation. This can only be verified in like Photoshop, where you put the second image above the first and set the second image to "Difference". If the layer is completely black, then it's 100% the same. But this will rarely happen.

Can you tell me how to put the output directory path as a quick setting? It's better than nothing.

User Interface -> Quicksettings list

[CHollman82]

The entire thing should be a deterministic process... I can't imagine where a source of indeterminism would come from. I found these statements agreeing: "Unlike other AIs Stable Diffusion is deterministic.", "The results from SD are deterministic for a given seed, scale, prompt and sampling method.", "Stable Diffusion is open and fully deterministic: a given version of SD+tools+seed shall always give exactly the same output."

...and this is what makes sense to me as a firmware engineer with 18 years of experience in software development. Without changing any settings you should get an identical file, to the byte, and that would produce the same checksum.

If you are getting different results without changing any generation settings then you're doing something weird, or you're getting bit-flip type errors in your GPU or something. I've only seen indeterminacy when I was writing my own ComfyUI nodes and I would re-seed the random number generator in the code for my node, which makes sense.

As far as I can tell when people call a sampler "non-deterministic" they don't mean that you will get a different output with the same settings... People say ancestral samplers, such as Euler-A, are non-deterministic but what they mean by that is that with increasing denoising steps the image doesn't "settle" onto a given form... this is because there is noise injection between steps, but the noise itself is deterministic at each step... so even when using Euler-A or other "non-deterministic" samplers you will get the exact same image if you generate with all the same settings, including the number of sampling steps.

But anyway, thanks for the tip about putting the output directory setting on the T2I tab.

[Woisek]

You did a nice write-up, but all I can say is: It is so 🤷‍♂️ and; Just test it. Generate a grid with all the different samplers and then let the images "flip book" through. Or better, put them in Photoshop and check them with the layer set to "Difference" to see the exact change.

[CHollman82]

I just did a test for you, using Euler-A I made an image with the prompt "A cute dog"... I then generated another image without changing anything and... exact same image, same checksum, no differences. That's how it should be. If you get two different images with the same settings something is wrong with your setup.

My file naming convention is a simple index counter and then a dash and the seed. You can see the index is incremented by one and the seed is the same:

[SenshiSentou]

I remember w-e-w on the dev discord mentioning there are sometimes some extremely small, imperceptible differences during the first few generations. Went back to look it up and it was attributed to likely be some artifact of VRAM contents ¯\_(ツ)_/¯ That said, it was described as a bug, and @CHollman82 is completely correct that the same settings on the same GPU and config should produce identical images. (And for the record, a checksum is performed on the contents of a file, so identical files == identical checksum. No manual faffing about with difference layers needed.)

I use the same workflow, and was actually gonna look into adding an "hr fix" tag to the output images, but I like a separate folder much more! So +1 from me on this

[w-e-w]

yeah it's either due to torch optimization or some strange behavior due to vram
I remember I also did some tests with different torch versions and it produces different results
whatever the actual cause it's not something that we practically should worry about

the difference is imperceptible to our eyes and the difference is less than what would be caused by jpeg compression artifacts

I was working on my extension that generate multiple highways past images on save first past image
because there's no need for me to upscale the same first pass image for hires pass input multiple times and so I implement a cache for upscalliung
what I found is that if I use the ceche image it would generate the image different from if I were to use the cache and still runs the upscalling pocess and discard the result
so the behavior is basically out of our control

note don't quote me on the cause, the cause is just my theory based on my understanding and what I have observed
I'm not an expert on low level stuff

[w-e-w]

I think I might be able to add this feature as an extension