🧩 IC Lora Layout

IC Lora Layout builds the side-by-side canvas that In-Context LoRA workflows need. In-Context LoRA (the "IC-LoRA" technique on Flux) works by placing two images on a single canvas - a reference on one side, the target region on the other - and letting a specially trained LoRA fill the target half based on what it sees in the reference half. The catch is you have to assemble that combined canvas correctly first, and split the result back apart after. This node is the assembler; its sibling "IC Lora Layout Crop" is the splitter.

The mechanism is layout math. You feed it image1 and image2, it normalizes them to a common height_size (default 1024) and stitches them into one image the LoRA will treat as a unit. The outputs give you everything you need for both ends of that round trip: ic_layout is the combined canvas you send into generation, mask_layout is the matching combined mask (so the model knows which side to generate versus preserve), and crop_image1 / crop_image2 are CROP objects - the geometry needed to pull each region back out of the generated result cleanly. The optional mask1 and mask2 let you carry per-image masks into that combined mask, for when you want to constrain within each half rather than treat the whole side as one block.

The inputs a beginner sets are the two images and height_size. That height is the one to think about: it's what both images get resized to before stitching, so it controls the working resolution of the whole IC-LoRA pass. Push it too high and you're generating a very wide canvas (two images side by side) that eats VRAM; too low and you lose detail. 1024 is a sensible middle for Flux.

Why this matters: IC-LoRA is one of the cleaner ways to do reference-guided generation on Flux - consistent style transfer, "same subject, new pose," garment or object transplant - precisely because it sidesteps adapters and control maps and just shows the model both images at once. But the layout bookkeeping is annoying to do by hand: get the stitching or the crop-back wrong and your output is misaligned garbage. Having a node that produces the canvas, the mask, and the crop geometry as a matched set is the difference between IC-LoRA being usable and being a fiddly manual chore. That's the whole value proposition here - it's not doing anything clever to the pixels, it's handling the geometry so you don't.

Install comes with the pack. ComfyUI Manager, search SDVN_Comfy_node; or cd ComfyUI/custom_nodes && git clone https://github.com/StableDiffusionVN/SDVN_Comfy_node, then pip install -r custom_nodes/SDVN_Comfy_node/requirements.txt from your ComfyUI root and restart. No weights for the node itself - you bring the Flux model and the IC-LoRA you're driving it with.

Troubleshooting. The most common problem is the round trip not lining up - if your cropped-back result is offset or the wrong size, make sure you're using the crop_image1/crop_image2 outputs from this node with the Layout Crop node, rather than eyeballing a manual crop; they carry the exact geometry. Mismatched aspect ratios between image1 and image2 can also produce odd stitching, so images of roughly comparable shape behave best. And remember this node only sets up the canvas - if the generation itself ignores the reference, that's the LoRA or the sampler settings, not the layout; confirm you actually have an IC-LoRA loaded and applied to the model doing the fill.