ποΈ Slice Combiner Hub
Stitch your processed slices back into one seamless image
- image_batch
- S1
- S2
- S3
- S4
- S5
- S6
- S7
- S8
- S9
- S10
- sliced_commons
- image
Slicing an image is the easy half. Putting the strips back together without a visible seam down the middle of every join is where tile-and-stitch workflows fall apart. Slice Combiner Hub is the "merge" end of Shima's sliced ecosystem: it takes up to ten individual slice images (or one batch), aligns them, and merges them with feathered alpha-blending into a single composite.
It's deliberately the mirror image of Sliced Image Hub. The Image Hub splits a batch into separate S1βS10 streams; the Combiner Hub accepts those same streams and glues them back. If you didn't fan anything out - you just have a batch from the Sliced Upscaler - wire image_batch in directly and it splits internally, then merges. Either path lands on the same merge logic.
The inputs
orientation-VerticalorHorizontal; must match how the slices were produced.overlap- the same overlap value used when slicing. The merge relies on it: each subsequent slice is placed back atprevious_position - overlap, and the overlap zone is where blending happens.feather_sizeandfeathering- blend width and master toggle. Feathering off forces overlap to 0 (hard-edged stacking, the "sliced but not blended" mode).image_batch- one batch input alternative to the individual streams.S1βS10- the ten individual slice ports.sliced_commons- the shared settings bundle; when connected, itsorientation,overlap,feather_size, andfeatheringoverride the widgets. This is the wire that keeps your merge in sync with your upscaler.
Output: one image. It also reports the orientation, slice count, overlap, and final resolution into a used_values display on the node - handy when the merge result looks wrong and you want to see what it actually assembled.
How the merge works
The node center-pads any slices that have mismatched dimensions (a slice that came back smaller gets padded symmetrically so nothing shifts off-axis), then walks the slices in order. The first lands at position zero; each following slice is written into the canvas at position - overlap, and in the overlap zone a linear gradient blends the incoming strip over the existing canvas. That gradient is capped at min(feather_size, overlap), which is a smart guard - it stops the blend from extending past the region where the two slices actually share pixels.
Installing it
Part of KDB-USJP/shima_wf:
cd ComfyUI/custom_nodes
git clone https://github.com/KDB-USJP/shima_wf
Restart ComfyUI. Pure torch/pillow, no extra dependencies.
The honest advice
For one-shot upscales, the Sliced Upscaler's built-in merge (its image output is the merged result) is enough and you don't need this hub at all. The Combiner earns its place when you want to process slices independently - per-slice detailing, per-slice LoRA, per-slice anything - and then reassemble. If your merged image shows hard seams anyway, the usual culprit is an orientation mismatch or an upstream node that didn't pass the same overlap through - that's exactly what the sliced_commons wire is supposed to prevent.
Inputs (19)
| Name | Type | Default | Description |
|---|---|---|---|
| orientation | COMBO | Vertical | 2 options: Vertical, Horizontal |
| overlap | INT | 640β1024 | β |
| feather_size | INT | 320β512 | β |
| feathering | BOOLEAN | true | β |
| image_batchopt | IMAGE | β | |
| S1opt | IMAGE | β | |
| S2opt | IMAGE | β | |
| S3opt | IMAGE | β | |
| S4opt | IMAGE | β | |
| S5opt | IMAGE | β | |
| S6opt | IMAGE | β | |
| S7opt | IMAGE | β | |
| S8opt | IMAGE | β | |
| S9opt | IMAGE | β | |
| S10opt | IMAGE | β | |
| sliced_commonsopt | SLICED_COMMONS | β | |
| allow_external_linkingopt | BOOLEAN | true | β |
| show_used_valuesopt | BOOLEAN | true | β |
| use_commonparamsopt | BOOLEAN | true | β |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| image | IMAGE | β |