Shima MultiPipe XL In
One pipe for the whole SDXL rig — refiner included
- image
- mask
- sdxl_tuple
- latent
- model
- vae
- clip
- positive
- negative
- refiner_model
- refiner_vae
- refiner_clip
- refiner_positive
- refiner_negative
- pipe
Shima MultiPipe XL In is the SDXL-grade packer: it takes the full base-plus-refiner payload and bundles it into a single PIPE_LINE output. Beyond the eight main signals, it also captures the sdxl_tuple (the SDXL conditioning tuple - the width/height/crop data both stages consume) and the four refiner signals (refiner_model, refiner_vae, refiner_clip, refiner_positive, refiner_negative), plus four dimension values defaulting to 1024. In, one wire out.
The idea is the pipe pattern from the utilities playbook: one bundle instead of a dozen wires. For SDXL specifically, this is where it shines, because a base+refiner rig is exactly the setup whose graph explodes - model, clip, vae, conditioning ×2, tuple, refiner model, refiner clip, refiner conditioning ×2, and dimensions. Squashing that into a single PIPE_LINE is the difference between a canvas you can read and a plate of spaghetti. The sdxl_tuple riding along is the subtle win: it's the wire everyone forgets when they hand-bundle an XL workflow.
The mechanism
execute assembles a fixed-order tuple - image, mask, sdxl_tuple, latent, model, vae, clip, positive, negative, refiner model/vae/clip/positive/negative, then the four dimensions. All inputs optional; the pack's matching out node (MultiPipeOutXL) unpacks by position. The ordering is the contract, so stick to the pack's own in→out pairs.
The inputs that matter
- The signal sockets, especially sdxl_tuple and the refiner_ group - the ones that distinguish this from the 1.5 variant.
- image_width / image_height / latent_width / latent_height - default 1024 each, riding along so the consumer knows the target size.
Install
cd ComfyUI/custom_nodes
git clone https://github.com/KDB-USJP/shima_wf
then restart, or ComfyUI Manager → search "Shima". No models, no extra dependencies.
The honest take
This is the most defensible pipe node in the pack: an SDXL+refiner pipeline genuinely benefits from bundling, and the tuple plus refiner coverage is something generic pipe packs often make you assemble by hand. Two caveats, same as its 1.5 sibling. The PIPE_LINE type is Shima's own, so unpacking needs a Shima out node - check that the workflow you're copying actually includes the matching unpacker, or you'll hit a missing-node wall on load. And if you're not doing a refiner pass, this node is overkill; the 15 variant (or Multi Pass) is the right size. Also a housekeeping note: refiner_vae exists here but not on Multi Pass XL - the two "bundle everything" nodes disagree slightly on the refiner set, so if you're mixing passers and pipes in one workflow, check the sockets before you trust the wiring. Still, for a real base+refiner XL template, this is the one I'd reach for.
Inputs (18)
| Name | Type | Default | Description |
|---|---|---|---|
| imageopt | IMAGE | — | |
| maskopt | MASK | — | |
| sdxl_tupleopt | SDXL_TUPLE | — | |
| latentopt | LATENT | — | |
| modelopt | MODEL | — | |
| vaeopt | VAE | — | |
| clipopt | CLIP | — | |
| positiveopt | CONDITIONING | — | |
| negativeopt | CONDITIONING | — | |
| refiner_modelopt | MODEL | — | |
| refiner_vaeopt | VAE | — | |
| refiner_clipopt | CLIP | — | |
| refiner_positiveopt | CONDITIONING | — | |
| refiner_negativeopt | CONDITIONING | — | |
| image_widthopt | INT | 102464–18446744073709550000 | — |
| image_heightopt | INT | 102464–18446744073709550000 | — |
| latent_widthopt | INT | 102464–18446744073709550000 | — |
| latent_heightopt | INT | 102464–18446744073709550000 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| pipe | PIPE_LINE | — |