[Bug]: Very Obvious Seams during Outpainting

[LiJT]

What happened?

Hello devs!

Thanks for your hard work! As you can see from this screenshot, I m currently using a inpainting model called Anything-v3-inpainting https://civitai.com/models/3128/anything-v3-inpainting The bottom part has a straight line seam, and the new generated image is slightly darker than before. If I keep trying to generate from bottom part, this is what i get.

You can clearly see there is a color gradient from outpainting

I even tried build my own inpainting model following this instruction https://www.reddit.com/r/sdforall/comments/zyieht/how_to_turn_any_model_into_an_inpainting_model/

But unfortunately this problem still persist in Anything V4 and V4.5... I lose clue what to do next, Please help a brother out, Is there some setting i m missing?

I have already turned off "Apply color correction to img2img results to match original colors.", nothing works so far

Steps to reproduce the problem

1. Go to ....
2. Press ....
3. ... [etc]

What should have happened?

There should be no color shift change during each outpainting steps

Commit where the problem happens

e1a694281ee0d7fe410e913166644884ec048b82

What platforms do you use to access openOutpaint?

Windows

What browsers do you use to access the UI ?

Google Chrome

Browser Extensions/Addons

N/A

AUTOMATIC1111 webUI Commandline Arguments

--api

Additional information

No response

[seijihariki]

Hi! Will try to reproduce with this model

[zero01101]

it's probably not particularly helpful, but i've had a few custom merged inpainting models kind of not work as seamlessly as the "official" inpainting models and sorta wonder if it's just a bit of the stochastic luck of the draw :/ i believe other solutions like invokeAI and stablediffusion-infinity use https://github.com/vacancy/PyPatchMatch for even better results with (or without) an inpainting model which A1111 doesn't employ...

anyway, my computer's being an overheating jerk still at the moment, but just as quick suggestions, i can see you've decreased overmasking - you might want to try increasing it instead? otherwise, you could try painting a quick mask over the seam and leaving the prompts the same, and running the dream tool over the region again...

thanks for the kind words and sorry for the trouble in any case :)

[LiJT]

it's probably not particularly helpful, but i've had a few custom merged inpainting models kind of not work as seamlessly as the "official" inpainting models and sorta wonder if it's just a bit of the stochastic luck of the draw :/ i believe other solutions like invokeAI and stablediffusion-infinity use https://github.com/vacancy/PyPatchMatch for even better results with (or without) an inpainting model which A1111 doesn't employ...

anyway, my computer's being an overheating jerk still at the moment, but just as quick suggestions, i can see you've decreased overmasking - you might want to try increasing it instead? otherwise, you could try painting a quick mask over the seam and leaving the prompts the same, and running the dream tool over the region again...

thanks for the kind words and sorry for the trouble in any case :)

Thank you so much for your input sir!!! yeah for this particular model its has this seams regardless what I do, But when I try using the default SD1.5 inpainting model everything works just fine, I guess there must be something wrong with the merging process? I m not entirely sure... Lets leave it like that hopefully someone will provide a one-stop solution for this

[seijihariki]

@zero01101 We should add a simple "generate debugging images to test directly on auto1111.zip", so we can ask users to test image + mask directly on automatic1111 to check if it is actually an OO issue or something related to the model/automatic1111.