MultiPipe XL Out
The 19-way plug at the end of your XL wire
- pipe
- image
- mask
- sdxl_tuple
- latent
- model
- vae
- clip
- positive
- negative
- refiner_model
- refiner_vae
- refiner_clip
- refiner_positive
- refiner_negative
- image_width
- image_height
- latent_width
- latent_height
- discord link
If MultiPipe XL In is the collector, this is the distributer. MultiPipe XL Out takes a PIPE_LINE that an XL In node built and fans it back out into the nineteen outputs that make up an SDXL run - everything you'd need to feed a sampler, a refiner, a decode, or a resolution node without a single hardcoded value.
On the way out you get: image, mask, sdxl_tuple, latent, model, vae, clip, positive, negative, then the five refiner slots (refiner_model, refiner_vae, refiner_clip, refiner_positive, refiner_negative), then four ints (image_width, image_height, latent_width, latent_height), and a "discord link" string. That last one is a pack quirk - the author's Discord invite riding along the pipe. Wire it to a text node or ignore it; either is correct.
The refiner outputs are the SDXL two-stage story, and they're the reason this node has more sockets than the 1.5 Out. If you run the classic base-then-refiner pipeline, wire refiner_model, refiner_clip, refiner_positive, and refiner_negative into a second-stage sampler, with refiner_vae if you want a dedicated refiner decode. If you don't run a refiner, leave them dangling - whatever the In side packed (or didn't) comes out as-is, and unwired slots are harmless here.
Mechanically it's positional tuple unpacking, same as its 1.5 cousin, which means pairing matters: this node must sit at the end of a pipe built by af_pipe_in_xl. The XL tuple has extra middle members - the sdxl_tuple and the refiner quintet - that the 1.5 Out doesn't know about. Feed it the wrong pipe and everything downstream shifts by five slots and breaks in confusing ways.
One asymmetry worth knowing before you design around it: unlike the 1.5 Out, this node does not pass the pipe through. Nineteen outputs, and no PIPE_LINE among them. If you want a second consumer of the same bundle, grab it at the In node or route it through a reroute before you unpack - you can't recover the bundle from this node's outputs once it's split.
The four int outputs (image_width, image_height, latent_width, latent_height) mirror what you fed the In side - defaults of 1024, SDXL's native resolution. Use them to drive aspect-ratio or tiling nodes so a workflow stays resolution-aware without magic numbers.
Install is the standard two-liner:
cd ComfyUI/custom_nodes
git clone https://github.com/aegis72/aegisflow_utility_nodes
Restart ComfyUI, or install via ComfyUI Manager by searching "AegisFlow Utility Nodes." No models to download, no requirements.txt - the pack is a single self-contained file. First startup after install may pause briefly while sibling fx nodes check their pip dependencies, but this node itself needs nothing beyond the pack.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| pipe | PIPE_LINE | — |
Outputs (19)
| Name | Type | Description |
|---|---|---|
| image | IMAGE | — |
| mask | MASK | — |
| sdxl_tuple | SDXL_TUPLE | — |
| latent | LATENT | — |
| model | MODEL | — |
| vae | VAE | — |
| clip | CLIP | — |
| positive | CONDITIONING | — |
| negative | CONDITIONING | — |
| refiner_model | MODEL | — |
| refiner_vae | VAE | — |
| refiner_clip | CLIP | — |
| refiner_positive | CONDITIONING | — |
| refiner_negative | CONDITIONING | — |
| image_width | INT | — |
| image_height | INT | — |
| latent_width | INT | — |
| latent_height | INT | — |
| discord link | STRING | — |