Ref Independent
Ten images, ten independent channels — when each reference needs its own prompt and latent
- clip
- vae
- image1
- image2
- image3
- image4
- image5
- image6
- image7
- image8
- image9
- image10
- cond_1
- latent1
- cond_2
- latent2
- cond_3
- latent3
- cond_4
- latent4
- cond_5
- latent5
- cond_6
- latent6
- cond_7
- latent7
- cond_8
- latent8
- cond_9
- latent9
- cond_10
- latent10
The pack's other multi-reference node, Ref Image Encode, shares one prompt across all your reference images. Ref Independent is the version for when each image needs its own text instruction - think a character sheet where image 1 says "front view, standing" and image 2 says "side view, arms crossed", and you want each reference to drive its own generation without cross-talk. It's the same family of instruction-editing workflows, just with N fully isolated channels instead of one shared one.
How it works
Each reference image goes through the full encode pipeline independently: VAE-encoded into its own reference latent, downscaled for the vision-language tokenizer, and conditioned with its own prompt via clip.tokenize(images=..., llama_template=...). The result is paired per image - cond_1 + latent1 for image 1, cond_2 + latent2 for image 2, and so on - so each channel carries its own reference and its own text. Nothing leaks between them.
Two details are worth knowing:
- Empty slots don't break the graph. If
num_imagesis 4 but you only wire up two, the unconnected slots encode their prompt as plain text with no image, so downstream nodes still get valid (if weaker) conditioning instead of a hard failure. That's a thoughtful touch, and it means you can build the graph for ten and populate it incrementally. - The latent outputs share a fallback. The
latentNoutput for an empty slot gets the first connected image's latent rather than nothing. If you're feeding latents to samplers, the first image is the one that matters.
The num_images counter (1–10) drives how many image/prompt input pairs and how many cond/latent output pairs show up, handled by the pack's frontend JS.
Inputs and outputs that matter
Required: clip, vae, num_images, and instruction (the shared system prompt - the Qwen-Edit-style default is fine for most edit models). Optional per-slot: image1–image10 and prompt1–prompt10.
Outputs are strictly alternating: cond_1, latent1, cond_2, latent2, ... up to cond_10, latent10. Wire each cond_N into a sampler's conditioning and latentN into its latent input, one sampler per reference if that's the plan - or merge the conditionings if you want them composited.
The catch, honestly
This node is the most flexible of the trio and also the least forgiving. Because it needs clip and vae both wired and produces up to 20 output slots, it's genuinely more graph to manage than the shared-prompt version. If all your references can ride the same instruction, Ref Image Encode is the simpler tool and this one is the overkill. Reach for it when the per-image prompt is the whole point - multi-character scenes, product variations, angle sheets - not as a default. And as with its sibling, it needs a vision-language CLIP (Qwen2.5-VL or the Qwen3-4B that ships with Flux 2 Klein); a plain SD CLIP will fail at tokenize time. Change num_images before wiring - shrinking removes slots from the top and can drop the last wire.
Installing it
Same pack, same one-line install:
cd ComfyUI/custom_nodes
git clone https://github.com/electricty00/ComfyUI-Toggle-Pass
restart, and it shows up under Toggle-Pass in the node menu. No requirements.txt, no pip deps - just ComfyUI's bundled torch/PIL/numpy. It's a small personal pack, so this node is essentially unmaintained-looking by big-project standards, but it's been around since the pack's May 2026 start and the core encode logic is solid.
Inputs (24)
| Name | Type | Default | Description |
|---|---|---|---|
| clip | CLIP | — | |
| vae | VAE | — | |
| num_images | INT | 11–10 | — |
| instruction | STRING | Describe the key features of the input image (color, shape, size, texture, objects, background), then explain how the user's text instruction should alter or modify the image. Generate a new image that meets the user's requirements while maintaining consistency with the original input where appropriate. | — |
| image1opt | IMAGE | — | |
| prompt1opt | STRING | — | |
| image2opt | IMAGE | — | |
| prompt2opt | STRING | — | |
| image3opt | IMAGE | — | |
| prompt3opt | STRING | — | |
| image4opt | IMAGE | — | |
| prompt4opt | STRING | — | |
| image5opt | IMAGE | — | |
| prompt5opt | STRING | — | |
| image6opt | IMAGE | — | |
| prompt6opt | STRING | — | |
| image7opt | IMAGE | — | |
| prompt7opt | STRING | — | |
| image8opt | IMAGE | — | |
| prompt8opt | STRING | — | |
| image9opt | IMAGE | — | |
| prompt9opt | STRING | — | |
| image10opt | IMAGE | — | |
| prompt10opt | STRING | — |
Outputs (20)
| Name | Type | Description |
|---|---|---|
| cond_1 | CONDITIONING | — |
| latent1 | LATENT | — |
| cond_2 | CONDITIONING | — |
| latent2 | LATENT | — |
| cond_3 | CONDITIONING | — |
| latent3 | LATENT | — |
| cond_4 | CONDITIONING | — |
| latent4 | LATENT | — |
| cond_5 | CONDITIONING | — |
| latent5 | LATENT | — |
| cond_6 | CONDITIONING | — |
| latent6 | LATENT | — |
| cond_7 | CONDITIONING | — |
| latent7 | LATENT | — |
| cond_8 | CONDITIONING | — |
| latent8 | LATENT | — |
| cond_9 | CONDITIONING | — |
| latent9 | LATENT | — |
| cond_10 | CONDITIONING | — |
| latent10 | LATENT | — |