Nano Banana Eye Match

Think of NanoBananaEyeMatch as the no-frills cousin of NanoBananaEdit, the pack's flagship gaze node. Where NanoBananaEdit compares, verifies, and retries, this one just does the edit: take an image, look at a target image's gaze direction, shift the first image's eyes to match, and hand you the result. One API call, no comparison step, no retry loop. It's the cheaper, faster, dumber version - and sometimes that's exactly what you want.

The "dumber" isn't a jab. The workflow here is: InsightFace detects the gaze direction in target_image (left, right, slightly up, at the camera), the node auto-builds a prompt - "Edit only the eyes in this photo so that both pupils look to their left" - sends a face crop to Google's Nano Banana image API, then pastes the edited eye region back onto the original with an elliptical soft mask and a Gaussian blur. Only the face/eye crop ever leaves your machine, which is the design trick that keeps the edit surgical: the model can't change the background because it never sees the background. The blur radius for that paste-back is blend_radius, default 30.

Where it fits versus NanoBananaEdit

This is the honest decision you have to make between the two:

• NanoBananaEyeMatch - one edit call, always applies. Cheaper per run, faster, and great when you know the source is already wrong and don't want to burn credits on a comparison that will just say "edit it."
• NanoBananaEdit - compares first, and only edits if the gaze actually differs. If your source is already close to the target, EyeMatch will happily re-edit an already-matching pair and spend money to make it subtly worse. NanoBananaEdit would have skipped.

So: EyeMatch for batch "fix everyone's gaze to match this reference" work where speed and cost matter; NanoBananaEdit when accuracy and not-wasting-calls matter more. The code literally can't verify its own output, so if the API half-succeeds, you get what you get.

Inputs and outputs

• image - the face to edit.
• target_image - the reference whose gaze direction gets matched.
• api_key - Google AI Studio key, required; blank raises an error before any call.
• model - Nano Banana 2 (Flash) (default, the gemini-3.1-flash-image-preview model) or Nano Banana Pro (gemini-3-pro-image-preview).
• output_quality - original, or downscale to 512/1024/2048 to save API cost.
• blend_radius - paste-back feathering, default 30.
• save_debug - dumps intermediates to ruucm-comfy/debug_output/.

Outputs: edited_image (IMAGE), used_prompt (STRING - the auto-generated prompt, useful for understanding what it asked for), and debug_info (STRING).

Setup and gotchas

It ships in Ruucm's ComfyUI Nodes, same install as the rest:

cd ComfyUI/custom_nodes
git clone https://github.com/ruucm/ruucm-comfy

Restart ComfyUI, then find it under "image/ai". You'll need the insightface + onnxruntime-gpu dependencies from the pack's requirements.txt (InsightFace auto-downloads the buffalo_l model pack on first use) and a paid Google AI API key - this is a per-image API call, not a local model, and Nano Banana is billed per generation. It's also aggressively censored, so if the API refuses the edit you get a RuntimeError: No image in API response and nothing else - no partial result to salvage.

The verdict: for a one-shot "make this character look where that other photo looks" job, this is the leanest tool in the pack. Just don't ask it to check its homework - it doesn't.