Reference Chain Conditioning (Base64)
The API-Facing Sibling Node
- conditioning
- neg_conditioning
- vae
- conditioning
- neg_conditioning
- first_image_scaled
The sibling node in this pack does the same job as Reference Chain Conditioning - take several reference images, scale them, VAE-encode them, and append them as reference_latents to your conditioning - except the images arrive as base64 text in a widget instead of files dragged onto a list. Same pack, same install, same mechanism, one different input. If you never touch ComfyUI's API, you can safely stop reading here and use the main node instead. This one is for the automation crowd.
Why base64?
The main node needs image files sitting in your ComfyUI/input folder. That's fine when you're clicking around, but it's a chore when you're driving ComfyUI from a script or a hosted endpoint - you'd have to upload every reference, track filenames, and clean up after. Here you just hand over the bytes. The widget takes a JSON array of base64 strings, accepts data:image/png;base64,... URLs (it strips the prefix), and will even take one bare base64 string with no array wrapper. Each one is decoded with PIL, scaled to the target megapixels, VAE-encoded, and appended to both the positive and negative conditioning - the same conditioning_set_values(..., {"reference_latents": [latent]}, append=True) call the main node and ComfyUI's core Reference Latent nodes use.
The inputs
Mostly a mirror of the main node: conditioning and neg_conditioning (both required - don't forget the negative, it bites here too), vae (the edit model's own), upscale_method (default lanczos), and scale_megapixels (default 1.0). The only real difference is:
- images_base64 - a multiline STRING widget holding a JSON array of base64 strings.
Outputs are identical: conditioning, neg_conditioning, and first_image_scaled (a preview tensor of the first image after scaling).
Where you'd actually use it
Any place the images aren't on the ComfyUI host yet - a submit script that encodes the files it was given, a queue service, an API wrapper. In a workflow file it looks like a giant blob of text, which is ugly but portable: the whole workflow is self-contained, no input-folder state to manage.
Gotchas
- It doesn't validate like the main node. The file version has a
VALIDATE_INPUTSstep that tells you up front when a file is missing; this one just tries each image, prints[ReferenceChainConditioningBase64] Warning: Failed to process image Nto the console on failure, and moves on. If all of them fail, you get the 1×1 black fallback tensor and your conditioning passes through unchanged - which silently produces a useless image if you don't watch the console. - The JSON must parse. A stray newline or comma in
images_base64and it falls back to treating the whole thing as one base64 string, which then fails. Keep the widget clean: a proper["...", "..."]array. - Workflow bloat. Base64 inflates binary by ~33% before you even multiply by several images. Fine for a one-off API call; miserable if you're saving these as reusable templates.
Installing
Same as the main node - it ships in the same repo, so installing "Reference Chain Conditioning" from ComfyUI Manager, or git clone https://github.com/remingtonspaz/ComfyUI-ReferenceChain.git into custom_nodes, gives you both. No extra dependencies, no models to download, restart ComfyUI and go. If your need is interactive, use the drag-and-drop node; if it's programmatic, this is the one.
Inputs (6)
| Name | Type | Default | Description |
|---|---|---|---|
| conditioning | CONDITIONING | — | |
| neg_conditioning | CONDITIONING | — | |
| vae | VAE | — | |
| upscale_method | COMBO | lanczos | 5 options: nearest-exact, bilinear, area, bicubic, lanczos |
| scale_megapixels | FLOAT | 1.000.01–16 | — |
| images_base64 | STRING | [] | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| conditioning | CONDITIONING | — |
| neg_conditioning | CONDITIONING | — |
| first_image_scaled | IMAGE | — |