-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Masked Area Resized to Wrong Final Dims. #55
Comments
Hi, when upsizing/downsizing, it is expected that the resize factor is not perfect and some issues could show up like these - however, if you set some blur and blend this should be unnoticeable. Could you try this? |
I did. Even with a large blur it's noticeable. The problem is mainly that the final masked images are enlarged. Even with lots of blur, the middle content still ends up being too large and the blurred transitions don't make sense. Normally, feathering anywhere from 4-50 pixels depending on resolution and denoise is enough for the transition to match up perfectly, but not here. It can't match up. If you look at the bottom right corner, that's where the expansion seems to be going towards the most. I'll show with the same examples I had last time. Without blurWith generous manual blurringI really would expect both of these to be pixel-perfect around the edges and maintain proportions, even if they have been through a few size conversions (which they shouldn't either, since the size of the selection was within the range set and a multiple of 2 and 64). There isn't any denoising being applied here, just the same image pasted back. I tried a feather of 5 pixels and the transition was still unnatural. It's worse when the image is denoised with a model too because all the reference points are wrong. I realize this may not seem like that big of an issue to you. In my mind the gifs don't illustrate it that well though. It also compounds if you inpaint an area multiple times, or inpaint details within an inpaint etc. For now at least, I can still use your node in free size mode and use my own node to do the resizing, but still I felt that it would be helpful to open an issue because this problem feels significant and not known. The actual stitching part works really well though, massive time saver that I didn't have to code that 😆 |
which node are you using for resizing? |
@revolutioncom123 A node I wrote that I haven't made public. I can open up a repo if you want, but it's very much a WIP with no guarantee that it's going to get support or updates, also the exact behavior might change on a whim lol (I like to think I make changes that make sense though). |
I am suffering in a lot of render with wrong seams on the renders.You would help me a lot if you can open a repo for your custom node. |
thanks , i really appreciate you are amazing @poipoi300 |
Hey, first of all, thanks a lot for the nodes. I'm trying to re-create the experience I have with a krita + A1111 plugin but with ComfyUI and your nodes greatly expedite that process.
Trying a simple workflow though, I noticed that crops and re-pastes are slightly off when using either forced or ranged size, even when the masked area should not have its size changed (e.g. 1024^2 on all fronts). Here is an example of that.
Free size
Ranged size 512^2 to 1344^2. (somehow slightly worse than forced size)
As you can see, the stitch has expanded the image beyond the masked area. Since this occurs on all sides, it's a bigger issue than the screenshot shows; the masked content ends up being enlarged. In Krita specifically, it's also annoying because the selection needs to be grown by a few pixels to correctly select all added pixels.
Below is a minimum reproducible example to demonstrate the issue.
![image](https://private-user-images.githubusercontent.com/80789459/397099372-342a42e0-f4f8-48be-85c6-596b8f76b5fa.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MzkzMjc2ODYsIm5iZiI6MTczOTMyNzM4NiwicGF0aCI6Ii84MDc4OTQ1OS8zOTcwOTkzNzItMzQyYTQyZTAtZjRmOC00OGJlLTg1YzYtNTk2YjhmNzZiNWZhLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTAyMTIlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwMjEyVDAyMjk0NlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTY5NTJlY2NiOGU1MzdjZTVhNGRlMDY5ODUzZWEyY2JkMjFjYjU3MjdlMmFmNGM2ODQ1ZDhjY2VmZWNmMDA0NmQmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.v1h3TxPzPh3MVXOgBNETLKmda56zoKF2r84-KamOJss)
is something you're willing to do to test/debug, but it does make it very easy to see if something is wrong visually.
I don't know if installing krita and the
I know this is not an issue with the krita plugin because using your node in free size mode with a rescale factor of 1 returns a completely unmodified image.
As an aside, if it's something you're interested in, I recommend looking at the
(search for sddebz_highres_fix) system. In my experience, it's been the best in terms of simplicity and results quality. There is high control, but it's slightly limited in that the max size only really makes sense for squares as some rectangles can usually be generated with one length significantly surpassing the maximum length for a square. I think there's probably some frontend logic for where to paste the image too, though I haven't looked into that part of the code.
The text was updated successfully, but these errors were encountered: