Nodes/ARC NanoB Gemini/NanoB Reference Stacker
ComfyUI Node

NanoB Reference Stacker

Hand the Nano Banana Editor Fourteen Reference Images (or Just One)

By DHan315·Created a day ago·Updated a day ago· 0
NanoB Reference Stacker
  • ref_image_1
  • ref_image_2
  • ref_image_3
  • ref_image_4
  • ref_image_5
  • ref_image_6
  • ref_image_7
  • ref_image_8
  • ref_image_9
  • ref_image_10
  • ref_image_11
  • ref_image_12
  • ref_image_13
  • ref_image_14
  • references

Google's Gemini image models - the Nano Banana line - can look at up to 14 images while they edit one. "Keep this character's face, swap in that jacket, light it like this third photo" is a normal request for them. The NanoB Reference Stacker is the node that bundles those donor images together and feeds them to the editor (NanoB Gemini Editor) in this ARC fork of comrender's NanoB-Edit-Gemini. It's the pack's wiring convenience, and it does one job well.

How it works

Fourteen optional image sockets (ref_image_1 through ref_image_14), collected in socket order into a single NANO_REFS list. Anything you don't wire is skipped, so a one-reference edit and a fourteen-reference character pack ride the same node. There is no weighting anywhere - the fork removed weight sliders in favor of letting the model do its own judgment. Socket order is the signal: the first image you wire is "Reference Image 1", the second "Reference Image 2", and so on.

Two details worth knowing:

  • The node grows as you wire it. A bundled frontend extension hides empty sockets, so a fresh node shows just ref image 1. Connect that and the next slot appears, up to the 14-image cap. People sometimes think it's broken when they only see one input - it's not, that's the design.
  • The numbered references are addressable in your prompt. The editor normalizes shorthand like "ref 2" or "reference image 2" into the exact "Reference Image 2" label it sends to Gemini, so you can write "put Reference Image 2's outfit on the person" and the model knows which picture you mean.

That last point is the real mechanism, and it's worth spelling out: this pack doesn't just concatenate images and hope. Each stacked image gets sent to the API as a clearly-labeled donor - the request text to the model is explicit that a reference supplies traits only, and that its pose, framing, background and lighting must not be copied onto your canvas.

The input that's NOT here

The most common beginner trap: thinking the first image you stack is the image you're editing. It isn't. Google's own docs describe first-image-as-edit-target for many-image calls, but this editor makes roles explicit instead of positional. The image you actually want changed goes into the editor's separate image socket; everything you stack here is a donor reference the model should borrow traits from. If you stack the image you meant to edit, the model gets told it's a donor reference and it'll happily keep it pristine while editing... whatever else is in the request. Wire your edit target straight into the editor, and put only donors in the stacker.

Inputs and outputs

  • ref_image_1 … ref_image_14 (IMAGE, optional) - the donor images, in the order you want them numbered. You can fill one or all fourteen; unconnected slots are ignored.
  • references (NANO_REFS) - the bundle, into the editor's references socket.

Install

Part of the same pack as the editor it feeds:

cd ComfyUI/custom_nodes
git clone https://github.com/DHan315/ComfyUI-ARC-NanoB-Gemini

or search "ARC NanoB Gemini" in ComfyUI Manager, then restart. Zero pip dependencies, zero model downloads - this is an API wrapper, so the real requirement is a Google Gemini API key (GEMINI_API_KEY env var or the editor's key field), and your reference images get JPEG-encoded and sent to Google's servers. That's worth keeping in mind for anything private, and it's why you shouldn't wire in huge images needlessly: each reference you add makes the request payload bigger.

Troubleshooting

  • "Only one socket shows." Wire it - the rest reveal as you go, up to 14.
  • "The output won't connect to the editor." It plugs into the editor's references input specifically (the NANO_REFS type). If you're aiming at the image socket, that's the edit target and it wants a plain IMAGE, not the bundle.
  • Character drift across several references. The pack's own guidance: per-model, Google recommends capping how many character-consistency refs you lean on (roughly 4 for Gemini 3.1 Flash Image, 5 for 3 Pro Image) even though the node allows 14 object references. And keep source images sharp - a blurry, low-res reference gets you a blurry, low-res transfer.
  • Output looks off / geometry shifted. If you're compositing the result back into a masked workflow, use the editor's match_input aspect-ratio mode - the fork rebuilt that path to pad rather than stretch, specifically so downstream masks don't break.
CategoryNanoGemini/Reference

Inputs (14)

NameTypeDefaultDescription
ref_image_1optIMAGE
ref_image_2optIMAGE
ref_image_3optIMAGE
ref_image_4optIMAGE
ref_image_5optIMAGE
ref_image_6optIMAGE
ref_image_7optIMAGE
ref_image_8optIMAGE
ref_image_9optIMAGE
ref_image_10optIMAGE
ref_image_11optIMAGE
ref_image_12optIMAGE
ref_image_13optIMAGE
ref_image_14optIMAGE

Outputs (1)

NameTypeDescription
referencesNANO_REFS