心宝❤局部裁切贴回

If BananaLocalCropPreprocess is the "cut it out" half of the local-edit chain, this node is the "sew it back in." You've regenerated a masked region with the Banana node, and now you need the new region dropped onto the original image at exactly the right place, with the right scale, blended so nobody can find the seam. That's the whole job.

It has no widgets at all - three required inputs and one output. Everything about how to paste is carried in the data flowing through it, which is the honest design: the geometry decisions were made upstream in the preprocess node, and this node just executes them.

The three inputs

• banana_image (IMAGE) - the image that came back from the 心宝❤Banana generation pass. This is the regenerated content for the region, usually the crop output from the preprocess node, or the full image the model returned.
• region_data (BANANA_REGION_DATA) - the geometry from BananaLocalCropPreprocess: where the region was, at what scale, with what offset. This is what tells the paste node where the pixels belong.
• binding_context (BANANA_BINDING) - and here's the catch. The tooltip is blunt: the binding must have been activated on the Banana node already. This isn't optional decoration; the paste uses the binding context to align the region to the original image's layout. If the binding was never wired into the Banana node during generation, pasting back is working off stale or missing context, and your "100% no-offset" trick quietly stops being no-offset.

The one output

image - the original image with the regenerated region composited in. Wire it to a preview, a save node, or onward into the rest of your workflow. It's an IMAGE like any other; the pack doesn't care what you do with it afterward.

Why the chain is shaped this way

The KB's masking-and-detailing doc describes the universal loop - detect, crop and upscale, re-render, paste back - and this pack implements it against a cloud image model rather than a local sampler. That changes the stakes: the paste is the only step that happens on your machine, and it's the step where "no offset" is won or lost. Gemini is good at honoring a binding context and keeping everything outside the region pixel-identical; but the model can't place pixels back onto the original - that's purely a geometry operation, and it's this node's.

So the practical order of operations matters:

1. BananaBindingGenerate mints the binding context.
2. BananaLocalCropPreprocess cuts the region and emits region_data.
3. The Banana node generates the region with the binding_context wired in.
4. This node pastes banana_image back using region_data + binding_context.

Skip wiring the binding into step 3 and step 4 has nothing to anchor to.

Installing and gotchas

Ships in the comfyui-banana-li-linux pack:

cd ComfyUI/custom_nodes
git clone https://github.com/98624017/comfyui-banana-li-linux

Restart ComfyUI. Uses the pack's opencv-contrib-python and Pillow for the compositing - no extra install, no model downloads.

Where people get burned: pasting the wrong banana_image. If you wire the full original image into banana_image instead of the region crop, you're compositing the whole thing back on itself and the region never changes. The paste expects the regenerated region content; the preprocess node's output is what belongs here. If the seam shows, it's usually not this node's fault - revisit blend_slider and padding_slider upstream, or force a force_refresh on the binding node if you changed the base image.