🦊 RS Tile Assemble

Tiling an image to fit in VRAM is easy. The hard part is putting it back together so the result doesn't look like a patchwork quilt. That's the whole job of RS Tile Assemble, the companion to RS Tile Adjustments in the RaykoStudio pack: take a batch of processed tiles, lay them out exactly where they came from, and feather the overlaps so the joins vanish.

If you've ever glued a tiled-upscale workflow together by hand - pasting tiles, then masking the seams in an editor - this is that step done properly. It's also the honest answer to the "patchwork artifacts" problem the community keeps warning about with tiled upscaling: when each tile is processed independently, without overlap blending you get a visible grid on the final image. This node is the blend. The pack behind it is a one-developer project (the author posts updates on r/StableDiffusion as Reykoon), so the README is your manual - and it's refreshingly short for exactly this node.

How it works

It rebuilds the image row by row, using the positions recorded by the splitter to know how much each neighbouring pair overlaps. Where two tiles overlap, it fades between them with a linear gradient mask over a strip whose width is feather_size - clamped to the actual overlap so it never blends past the shared region. Where tiles don't overlap (overlap_rate 0, or edge cases), it just pastes them side by side. Everything runs through Pillow, no GPU, no model, milliseconds.

One thing the source makes clear: the geometry comes from positions, not from guessing. The batch order maps to positions in order, so tiles must arrive in exactly the order RS Tile Adjustments emitted them. Don't shuffle the batch between split and assemble.

The inputs that matter

• tiles - the processed IMAGE batch. Wire this from whatever did the work: an upscaler, a KSampler pass on each tile, whatever.
• positions, original_size, grid_size - the metadata trio from RS Tile Adjustments (LIST/TUPLE sockets match one-to-one). Positions drive the overlap math; grid_size tells the node the row/column layout. original_size is accepted for completeness, but the assembly math doesn't actually use it - positions carry the weight.
• feather_size - the one knob that matters, 0–512 in steps of 8, default 64. It's the blend strip width. Start at 64. Visible seams → raise it. Detail going soft or double-exposed at the joins → lower it. If your overlap_rate was low, the blend clamps to the overlap anyway, so lowering feather is the right move there, not raising it.

The single output is FINAL_IMAGE, ready for Save Image or another processing pass.

Installing

Same pack as the splitter. ComfyUI Manager → search "ComfyUI_RaykoStudio", or:

cd ComfyUI/custom_nodes
git clone https://github.com/Raykosan/ComfyUI_RaykoStudio.git

restart ComfyUI. No models to download. It's torch and Pillow only, so it works on the most barebones ComfyUI install. (The pack's requirements.txt lists pycairo and opencv, but those serve the text and adjustment nodes - nothing here touches them. And if a module does fail to import, the pack skips just that module rather than killing the whole pack, so a missing RS node alongside working ones means one specific module errored; check the ComfyUI console for "Module import error".)

Troubleshooting

• Seams visible: raise feather_size in steps of 8 - and check that overlap_rate on the splitter wasn't zero or near-zero, because the blend can't be wider than the overlap.
• Soft, mushy joins or ghosting: feather is too high for your overlap. Lower it.
• Pieces in the wrong place: you reordered or dropped tiles. The node has no way to know - it trusts positions.
• Feedback loop / hang: the README is explicit that this is meant to be a linear split → process → assemble flow. Don't feed the assembled image back into the tiling node within the same prompt execution; keep it one-way.

That's the whole deal. Two RaykoStudio nodes, one on each side of your per-tile processing, and the seams disappear. On a small GPU this is the difference between "can't upscale this" and "sure, done."