Outpainting for #405

[carson-katri]

I changed the way outpainting works for better performance and flexibility. Instead of specifying the expansion on each axis, it uses the specified image size and an origin point.

For example, to extend a 512x512 image to the right:

1. Set an image size to specify the outpaint cursor area (e.g. (512, 512))
2. Set the origin point to (448, 0) for a 64px overlap, `(384, 0) for a 128px overlap, etc.

It will only run SD on a 512x512 area, and then overlays it on an extended image at the end.

An inpainting finetuned model must be used for outpainting.

[NullSenseStudio]

So far mostly works great, some issues though.

When the outpainted image gets large enough I'm receiving this error right after the final image gets placed in Blender. I'm assuming it has to do with it being done in a background thread and not Blender's main thread.

  File "...\dream-textures\operators\dream_texture.py", line 147, in done_callback
    image['dream_textures_hash'] = image_hash
AttributeError: Writing to ID classes in this context is not allowed: 388423733, Image datablock, error setting Image.dream_textures_hash

Also for some reason there is color shifting occurring in parts of the image that aren't even being outpainted to at the time.

[carson-katri]

To fix the threading issues, the Actor class could use an app timer instead of a Thread to handle response messages on the frontend.

[carson-katri]

I haven't had it happen yet with this implementation, but it seemed pretty random in the first place so hopefully this really did fix it.

One drawback of this approach is it removes the ability to block via the Future:

Generator.shared().prompt_to_image(...).result()

Instead you need the more verbose

Generator.shared().prompt_to_image(..., _block=True).result()

I don't think this is too bad considering it's internal API.
And perhaps we shouldn't block either way for UX.

[NullSenseStudio]

Perhaps the _send() function could remain how it was. Have a single threading event for each future that can be waited on for result() rather than adding in another callback. Then only create app timers when callbacks are run.

I suppose callbacks wouldn't run in this setup if result() is called on the main thread before completion, but I'd think you'd strictly use one or the other anyway.

[carson-katri]

I think 9480c4b works the way you described, which does seem a bit better than the artificial delays that come with using timers as a thread.

The hf_list_installed_models calls in preferences were left with _block=True as they were deadlocking when Blender is launched from VS Code. It seemed to work OK when opening Blender manually though.

[NullSenseStudio]

Also for some reason there is color shifting occurring in parts of the image that aren't even being outpainted to at the time.

I've tracked this down to being caused by save_temp_image(). Had an image generated, made a copy via that function and brought it back into Blender with the same color shifting being visible. Perhaps it could be sent to the backend as an ndarray instead of making a temp file?

[carson-katri]

[NullSenseStudio]

Was just about to mention those axis needing switched. Really getting tired of whoever standardized the y axis going before x.

Anyhow, everything seems to be working as intended now!

[carson-katri]

Me too, it's bizarre. They put the height before the width argument in the pipelines too.