Ability to queue multiple areas like with PaintHua about openoutpaint HOT 19 CLOSED

Queuing now has been implemented, and seems to be working alright. Cancel button is also present and working okay.

For now, only queuing the same place and cursor size is forbidden, but in the future, for compatibility with #94, we may have to restrict more overlaps.

Changes are now in the main branch.

The issue will be closed as complete. For changes/specific improvements or bugs, a new issue should be opened.

from openoutpaint.

for what it's worth, this was an absolutely fantastic suggestion and implementation and is ridiculously fun

from openoutpaint.

I mean, they should be non-overlapping I guess? It shouldn't be too hard.

It would be great if the queue status endpoint wasn't broken though.

from openoutpaint.

I'm not sure what would be the best approach to handle overlaps; perhaps just mask out the areas that are ahead in the queue, or perhaps let the later results overwrite earlier results? There will likely be obvious seams where two generations conflict, but that already happen if two generations are done consecutively side-by-side; I would think most would consider it obvious that when the user forces the tool to produce seams, an additional inpaint will need to be done over the seam to fix things; but I have no idea if that really is that intuitive for most users.

from openoutpaint.

I think avoiding overlapping is more of a "It will be hell dealing with rendering this thing in a decent way" than actual consistency, as the way dreams are designed they will be written to the canvas in the order they are accepted.

from openoutpaint.

Will try implementing with just avoiding perfect overlap (two images generated at the exact same place) and see what happens. As we do have the index 0 to show behind selections, it should not be unusable.

from openoutpaint.

And... I will also try avoiding overlap of image selection navigation buttons probably.

from openoutpaint.

Could you give a look? It is for now a bare-bones implementation of queuing.

from openoutpaint.

Just git pull and run the script? Or do I need to do more to give it a try?

from openoutpaint.

you should need to git checkout testing

from openoutpaint.

Ah, ok

from openoutpaint.

I can't say I'm a professional tester nor anything; but so far, everything seems to be working as expected I think.

from openoutpaint.

Well, this will be merged into main probably tomorrow night, so there will be some time for testing.

Please keep the issue open as there are some features that should be implemented before merge. (future generation cancel button mainly), and maybe some visual queue order indicators.

And @zero01101, what I did with promises here is something I have never tried before. It seems to function pretty well, but if you think of a better way to do things please tell.

from openoutpaint.

if you think of a better way to do things please tell.

lmao i'm sitting here completely failing to figure out how to add a scrollwheel handler to the resolution slider because it's not part of toolbar, meanwhile you're over here implementing giant new features and doing async voodoo :D

this most certainly still applies ;)

from openoutpaint.

Is there a video of someone using this feature efficiently?
Maye I am doing something wrong but when I queue multiple things the "seams" never work since it often starts building the next image before the previous one has been decided on. So I still have to wait and select the final image before queuing the next one in order not to get seams.

Am I using this feature incorrectly?

from openoutpaint.

Is there a video of someone using this feature efficiently? Maye I am doing something wrong but when I queue multiple things the "seams" never work since it often starts building the next image before the previous one has been decided on. So I still have to wait and select the final image before queuing the next one in order not to get seams.

Am I using this feature incorrectly?

Since it's programed with the assumption you might not necessarily accept the first result that comes, it has no way of knowing what to merge with. The way I use it is to work on separate areas of the image independently; either expanding in multiple directions at once, or inpainting at non-overlapping and non-neighbouring regions (or making a mental note to inpaint over the seam after I pick the final result of multiple generations when those conditions are not met). Ah, and keep an eye out for existing seams; if you're not masking out all the seams in a region, the algorithm might assume having seams is part of the style of the image.

Oh, and if you're getting seams even without queuing, you might wanna play with the Mask blur and Overmask px settings.

from openoutpaint.

Ah, another thing, be sure you're using an inpainting model; non-inpainting models have a harder time blending things well sometimes.

from openoutpaint.

No I don't have seams problems in general, just with this feature

I see I guess the trick is to only use it to non-overlapping and non-neighboring regions as you mentioned which is not how I work on images
I usually concentrate on one region and expand it out because the prompt for non overlapping and non-neighbouring regions is usually slightly different. I can see this working when there are not many important details in the regions being expanded so the same exact prompt works for regions that are far from each other.

from openoutpaint.

You can change prompts while there is still stuff in the queue; if you have a slower machine or got it set to several iterations or something of the sort, there's plenty of time to even write new prompts from scratch while you're waiting.

from openoutpaint.