Shima MultiPipe 1.5 In
Stuff your whole SD1.5 pipeline down one pipe
- image
- mask
- latent
- model
- vae
- clip
- positive
- negative
- pipe
Shima MultiPipe 1.5 In is a packing node: it takes the eight main signals of an SD1.5 pipeline - image, mask, latent, model, vae, clip, positive, negative - plus four dimension values, and bundles them into a single PIPE_LINE output. One wire in, one wire out, and the whole generation payload travels as a unit. It's the same idea as rgthree's Context nodes and the classic "pipe" pattern: fewer wires crossing the canvas, one tidy bundle instead of a spaghetti tangle.
Why SD1.5-flavored? Because this variant's dimension defaults are 512 (both image and latent width/height), which is the resolution SD1.5 checkpoints expect. It's a hint about what you're building for, not a hard rule - the values are editable.
The mechanism
execute just assembles a tuple in a fixed order: (image, mask, latent, model, vae, clip, positive, negative, image_width, image_height, latent_width, latent_height). That ordering matters because the matching output side - the pack's MultiPipeOut15 - unpacks the pipe by position, not by name. Every input is optional, so you can pack a partial pipeline; the gaps become zeros/None in the pipe. To unpack the pipe at the far end of the island, you'll want the companion out node, which splits it back into individual typed sockets.
The inputs that matter
- The eight signal sockets (
image,mask,latent,model,vae,clip,positive,negative) - wire in whatever your pipeline has. - image_width / image_height / latent_width / latent_height - the dimensions, defaulting to 512/512 each. These ride along in the pipe so the consuming side knows the target size without you re-typing it. Note they're
INTinputs with a huge max; keep them sane multiples of 8.
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
The pipe pattern is genuinely useful - it's how you keep a big workflow readable, and the KB's plumbing doc is basically a love letter to the "bundle of connections down one wire" idea. But be warned: this is a Shima-proprietary PIPE_LINE type, so a Shima pipe only unpacks with a Shima node (or a compatible one that knows the same tuple layout). That's a lock-in worth knowing before you build your whole template on it. Also, the exact tuple order is the contract - if you hand this pipe to a node expecting a different layout, you'll get silent garbage, not an error. And honestly, for the pure bundling job, rgthree's Context or any of the well-trodden pipe packs do the same thing with a bigger ecosystem of unpackers; MultiPipe In 15 earns its place if you're already living inside Shima and want its defaults, not as the reason to install the pack.
Inputs (12)
| Name | Type | Default | Description |
|---|---|---|---|
| imageopt | IMAGE | — | |
| maskopt | MASK | — | |
| latentopt | LATENT | — | |
| modelopt | MODEL | — | |
| vaeopt | VAE | — | |
| clipopt | CLIP | — | |
| positiveopt | CONDITIONING | — | |
| negativeopt | CONDITIONING | — | |
| image_widthopt | INT | 51264–18446744073709550000 | — |
| image_heightopt | INT | 51264–18446744073709550000 | — |
| latent_widthopt | INT | 51264–18446744073709550000 | — |
| latent_heightopt | INT | 51264–18446744073709550000 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| pipe | PIPE_LINE | — |