Image Concatenate (Swwan) · 旧版兼容
The legacy two-up stitcher, and why you should use Concat Multi instead
- image1
- image2
- IMAGE
The display name has · 旧版兼容 on the end - "legacy compatibility." That's the pack being honest with you: this node is here so your old workflow keeps producing the same pixels it always did, not because it's the one you should pick today. Its register entry points at SwwanImageConcatMulti as the recommended entry point.
That doesn't make it useless. If you already have a graph built around it, understanding its behavior is the difference between a seam you can predict and a seam that surprises you.
The interface
Two required IMAGE inputs, image1 and image2. direction is an enum of four: right (the default), down, left, up. match_image_size is a BOOLEAN defaulting to true here - note that, because the modern Concat Multi defaults it to false.
One output, IMAGE.
How it actually behaves
Three things happen before the tensors are concatenated, and each one is a decision the node makes for you.
Batch mismatch gets filled by duplicating the last frame. If image1 is a batch of 1 and image2 is a batch of 4, the node repeats image1's final frame until they match. It's a sensible default and it's also completely silent, which is how a "why is my video 4 frames long" question starts. If your two inputs are meant to be different lengths, this node is not the place to reconcile them - fix the batches upstream.
match_image_size only resizes the second image. With it on, image2 is lanczos-resized to match image1 - height-matched with aspect preserved for left/right, width-matched for up/down. Image1 is never touched. So "matched" means "matched to image1's geometry," not "both resized to something sensible." If image1 is the odd one out, you get a canvas sized for the wrong image.
Channel count is padded with opaque alpha. A 3-channel RGB next to a 4-channel RGBA gets an alpha channel of 1.0s stapled on so the cat works. Reasonable, and worth knowing if you were hoping for transparency to survive a mixed-graph stitch.
Then it's a plain torch.cat along the width dimension for left/right and the height dimension for up/down, with the ordering flipped for left/up so image1 stays the anchor.
Should you use it?
For new work, no - reach for Image Concat Multi (Swwan), which takes the same direction and match_image_size arguments, handles more than two inputs, keeps image1's shape as the anchor across every step, and adds strip / grid / batch_grid layouts. It supersedes this node, Image Concat From Batch, and both Grid Composite nodes at once.
Keep this one if a legacy workflow depends on its exact batch-padding and single-sided resize behavior.
Install
cd /path/to/ComfyUI/custom_nodes
git clone https://github.com/aining2022/ComfyUI_Swwan.git
cd ComfyUI_Swwan
python -m pip install -r requirements.txt
Windows portable:
.\python_embeded\python.exe -m pip install .\ComfyUI\custom_nodes\ComfyUI_Swwan\requirements.txt
Restart ComfyUI, hard-refresh the browser, search Swwan. It's filed under Swwan/Legacy. No model downloads; the tensor work runs on whatever torch your ComfyUI already has.
One migration note that applies to every Legacy node in this pack: 1.0.0 moved 56 KJNodes-overlapping IDs to Swwan-prefixed IDs and deliberately registers no conflict aliases, because sharing a node ID with KJNodes is exactly what caused trouble for people running both. Old workflows therefore need the repo's migration tool:
python scripts/migrate_workflow.py old.json --dry-run
It save-copies by default and preserves the original file, so the dry run is free.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| image1 | IMAGE | — | |
| image2 | IMAGE | — | |
| direction | COMBO | right | 4 options: right, down, left, up |
| match_image_size | BOOLEAN | true | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| IMAGE | IMAGE | — |