Zuco Image2 Image to Image

The same cloud trick, but it can see your input

Zuco Image2 Image to Image is the sibling of the pack's text-to-image node, and it's where the cloud setup earns its keep. Instead of a blank latent, it takes a reference image - or a whole batch - ships it to OpenAI's gpt-image-2 through the Zuco API, and gets back an edited or re-imagined version. It's img2img and inpainting, except the model lives at https://api.zuco.ai/v1 and every run costs a fraction of a cent to a few cents depending on size.

Where this node shines is exactly where cloud models are strongest: strong prompt adherence and a model that actually looks at your input image. If you want to restyle a photo, change the contents of a scene, or fill something in, gpt-image-2 is genuinely good at following the instruction. The community reaction to the underlying model was the usual one - "not open source" - but nobody argues with the output quality. Just remember the deal you're making: paid, closed, and your images leave the machine to be processed by someone else's server.

How it works

Same family as the text-to-image node, different endpoint. Where the t2i node POSTs JSON to /v1/images/generations, this one builds a multipart form and posts to /v1/images/edits, the OpenAI-compatible image-edit endpoint. The model is fixed to gpt-image-2; the base URL is hardcoded to Zuco's.

The mechanics are worth knowing because they affect what the model actually sees. Reference images are converted to PNG before upload, and anything bigger than roughly 2048×2048 pixels gets downscaled first "to keep requests manageable" (the author's words). Feed it a batch of images and each one becomes an image[] part in the request. If you include a mask, it's encoded as a PNG alpha channel and attached as mask. The response comes back as base64 or a URL, is decoded into a tensor, and exits as the single IMAGE output.

The inputs that matter

The four shared inputs from the t2i node apply here unchanged - API Key (Bearer token, never saved to disk, pasted every run), prompt, width/height (default 1024×1024, must be multiples of 16, 256–3840, aspect ratio ≤ 3:1, and total pixels within a 0.64–8.3MP band), and output_format (png/jpeg/webp).

On top of those, two more:

• image (required) - the reference. A single image or a batch, either works.
• mask (optional) - the inpainting input. Per the tooltip, white areas are the ones that get changed. It requires a single input image, and it must match the reference's dimensions.

Output is IMAGE, wired straight into your usual save/preview nodes.

Installing it

It ships in the same pack as Zuco Image2 Text to Image, so one install covers both:

• ComfyUI Manager: search comfyui_zuco_image2 → Install → restart.
• Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/zuco1111/comfyui_zuco_image2
# restart ComfyUI

No extra pip packages - the pack rides on ComfyUI's existing runtime (aiohttp, certifi, numpy, torch, Pillow). No model downloads either; the "model" is the API.

Where people get burned

• Mask on a batch → the node refuses with "Mask can only be used with a single input image." If you're batch-processing with masks, that combination doesn't fly.
• Mask size mismatch → "Mask and image must have the same width and height." Resize the mask to the reference before it reaches this node.
• Big inputs get squished → that 2048×2048 downscale is real. A 4K source loses fine detail before the model ever sees it, so don't expect the API to work at your source resolution.
• The usual cloud-node pitfalls apply: blank key or prompt throws a validation error, size constraints bite exactly where the t2i article describes, and the 10-minute timeout means a slow generation isn't necessarily a hung one.
• This is a paid per-image API, and the community footprint for zuco.ai itself is essentially zero - small reseller, so keep an eye on billing. The model and endpoint are fixed; you can't point this node at a different provider.