#Inpainting always results in a slightly grainy image with reversed colors.

1 messages · Page 1 of 1 (latest)

swift veldt
#

I’m new to discord and programming in general so I’ll try to be as detailed as I can.

Every time I use the inpainting feature on the webui the output would result in a grainy, reversed color image no matter what I do. It doesn’t matter what model I’m using either and I’ll still get the same slightly grainy, reversed color result. It’s odd since when looking at the in-progress generating the colors look just fine, but only when the output is finished it looks bad. InvokeAI didn’t do this before and the colors and look of the image would turn out normal, but after an hour or so it seems stuck like this. I’m new and not a programmer so I’m not sure what I’m doing wrong. How do I fix this?

#

Edit: I’m using a MAC M1. I’m not sure how to edit the post.

ocean roost
#

Can you share an image showing what you’re describing?

swift veldt
#

This is what the inpainting output looks like (the person was supposed to be blonde with light skin, the background is supposed to be blue). Is there a fix for this?

IMG_7138.png
ocean roost
#

This is… very strange behavior. What models are you using?

#

This is with any/all prompts?

swift veldt
#

I got the same result from the same prompt with waifu-diffusion version 3 and stable diffusion 1.5. Changing the prompt doesn’t do anything since the result is still reversed colors and grainy.

When it’s in the process of generating the image the colors look fine and accurate but then once it’s done the colors are reversed and it looks bad, so it seems the processing part (the last step after generating) is the issue? Do you think this could be an InvokeAI issue or just my computer issue?

ocean roost
#

It’s hard to say - I’ve not seen this before from anyone using invoke

swift veldt
#

Well that sucks. I’ll try to see if this continues to happen with other images I try to I paint. For more information the original image was a compressed photo I uploaded (not an original stable diffusion generation), so maybe that affected the outcome?

It’s still bizarre to me since the colors look perfect in the generating stage so I’m not sure why the processing stage is failing with this. Restarting the terminal and refreshing the page didn’t do anything to fix this issue, so I’ll try seeing if it’s my computer issue by restarting it. InvokeAI was working before on my computer with inpaint so I’m not sure what happened. Do you know anyone else you might have answers to fix this issue?

ocean roost
#

It’s hard to say what’s happening - have you tried inpainting on an SD generation rather than an existing photo? What settings are you using for inpainting?

#

Are you able to generate txt2img without issues?

swift veldt
#

I just tried doing inpaitning on a non-existing photo (a stable Diffision generation that was from img2img, which worked fine) and surprisingly inpainting works so the colors are preserved and it doesn’t look grainy! 😄
I guess it’s that photo being compressed that was causing the issue? I just tried a version of the photo that wasn’t compressed and the output is just fine, no grainy and reversed colors. I guess this issue is “solved” as long as I avoid using inpainting on a compressed photo?

I tried Img2img and it works fine and I hadn’t had any issues with txt2img before so I’m not worried about that, so far my only issues were inpainting with occasionally glitchy results (which would be fixed by restarting the terminal or the computer) and recently inpainting with a compressed photo (which there doesn’t seem to be a fix yet). Thank you for your help with navigating this issue and finding a workaround, I’ll just try not inpainting/using compressed photos in the future.

ocean roost
#

For reference, can you share any example of a 'compressed photo'?

#

Might be a bug we can fix.

#

(or at least ought to understand!)

swift veldt
#

I can’t share the original compressed photo (personal original artwork) but I used an app called “Compress” from the App Store which shrunk the PMG image down from 3800 x 5000 that was 10.1 MB to 1900 x 2500 and is now 811 KB, so when clicking info on the photo in the Photos app it states “IMG_[4-digit number]-compressed”.

I think the same issue would happen if I use any other photo that is compressed (at least in the same manner I compressed it), but I can’t tell if this would be a universal issue for others inpainting compressed photos or just my computer. I haven’t tried img2img on the original compressed photo so I can’t tell if I would get the same result as I did with inpainting. I hope this helps you out and this issue can be fixed for other users. Again, thank you so much for your help.

#

*PNG, not “PMG”

lunar dagger
#

So it's definitely not a universal issue

#

And not related to image compression exactly... something must be going awry with the channels of the image or something

#

I'm reluctant to troubleshoot further at the moment, because in our upcoming 2.2 release we handle the images differently on the backend and I think this will be fixed.

#

However, from Photos app, you can File > Export and compress the image that way. Choose PNG when you do this. I do this all the time with my own photos and it works fine with the app. I suspect that the Compress app is doing something funky.

swift veldt
#

OK, that’s good to know! I’ll try to avoid using the Compress app in the future for stuff like this then. I used the Compress app on my phone and then sent it to my computer to use for inpainting to be specific, and when I look at the compressed version of the image through that method there is a dotted pattern for some colored areas (which might be expected for compressed images?) so maybe that pattern is what caused the colors and quality of the image to mess up?

I tried your method of compressing (via file and export on the computer instead of my phone) and the inpainting works fine as intended (at least as long as when the inpaint box isn’t too small, since then the results look glitchy and incomprehensible unless I make the inpaint box bigger). I’m not sure what the Compress app does to cause these issues or what channels of images entail (I’m not that knowledgeable on how the specifics of tech works) but I’m glad this issue will likely be resolved in the future. Thank you for your help.

lunar dagger
# swift veldt OK, that’s good to know! I’ll try to avoid using the Compress app in the future ...

I have no idea what the Compress app is doing but it ain't right lol. Hopefully it will work on the invokeai with the changes made.

You do need to keep that inpaint box close to 512x512 if possible, but we are working on a feature to let you use a smaller box and still get just as good of results as if you used a larger box. It takes whatever is in the smaller box, scales it up, does the inpainting, then shrinks it back down to the original size to paste back in. Pretty slick.

swift veldt
# lunar dagger I have no idea what the Compress app is doing but it ain't right lol. Hopefully ...

That sounds great! Looking again there is definitely a difference between the compressed photo from the Compress app and the compressed photo from file > export on my computer (the compress app photo had a tiny repeating dot pattern for the entire image you can see if you zoom in closely while the latter didn’t have this pattern and the colors transition seamlessly into each other).

Since this is a specific “niche” issue with just this specific app’s compression method I don’t feel too worried about the images compressed with it working in InvokeAI in the future since I know how to compress the image in a different way now. I’m glad we were able to get this sorted out, and I can’t wait for the new features for the webui in the feature. 🙂

magic zinc
#

I'd guess, based on the repeated dot comentn that it converted the image to a indexed PNG (like GIF is) rather than a RGB or RBGA especially with that level of reduction, your can usually get 10% or so reduction from changing to a more appropriate compression 'mode' so the level of compression, even allowing for the size reduction is a little suspicious in this regard too.

swift veldt