OpenOutpainter Serving Output IMG2IMG

The return trip for img2img jobs. OpenOutpainter Serving Input IMG2IMG unpacked the canvas's request; your inpainting branch did the work; this output node packs the result back into the A1111-style response and unblocks the HTTP request that's been waiting since the canvas POSTed to /sdapi/v1/img2img. The canvas then composites your generated image into place, mask and all, and you keep painting the next section.

It's structurally identical to the txt2img output node, with the same three required inputs: oop_request (threaded through from the Serving node), images (your final decoded IMAGE), and SEEDS (the seeds you used, wired in as a list - important if batch_size was more than one). No output sockets; this is a terminal node.

How it works

Command-aware and lazy. It only acts when the pending request is an img2img call and both images and SEEDS are present. When it does, it builds the response:

{"images": ["<base64>", "..."], "info": {"all_seeds": [123, 124, 125]}}

and calls finalize() on the request, waking the HTTP thread so the JSON can be written back to openOutpaint. Note it echoes info.all_seeds even though img2img requests in the A1111 API technically return all_subseeds - the pack just reuses the same shape for both, and openOutpaint is fine with it. The response the canvas cares about is images anyway.

The lazy inputs are the thing to be careful with. If images isn't connected to an actual IMAGE output, the node never triggers and the canvas hangs silently. Same if you accidentally wire it onto a branch fed by a different request type - this node only fires for img2img, and its txt2img sibling only fires for txt2img. Keep the matching input/output pair on the same oop_request chain.

Install and what breaks

The pack installs once: ComfyUI Manager (search "OpenOutpaint ComfyUI Interface"), or git clone https://github.com/without-ordinary/openoutpaint_comfyui_interface into ComfyUI/custom_nodes, then restart. Its only pip dependency is opencv-python; nothing to download model-wise.

The classic snag: a graph error before this node leaves the canvas waiting forever with no error on screen. The source's own workaround is to re-run the workflow with the same request_id so the pending request completes. And since this pack runs the API server inside a single workflow, don't add a second Serving node expecting it to handle more - the code explicitly warns that multiple serving workflows are unsupported. One workflow, one canvas connection, and this node is how the outpainted pixels get home.