TileView

TileView does one job: it takes an image and a TILE_PLAN and hands you back the four crops that plan describes, as a single image batch - image 0 is TL/TR/BR/BL, then image 1 TL/TR/BR/BL, and so on.

If you're using plain prompting, you can ignore this node entirely. It exists for the two reference paths in the pack: TiledAnimaLLLiteApply and TileKrea2Conditioning. Both of them want to see the picture one tile at a time, and they need the crop boxes to be identical to the boxes the sampler will evaluate. Cropping by hand - or with a generic image-crop node - gives you quadrants without the shared overlap, which is subtly wrong: the tile the sampler denoises is a bit bigger than the quadrant, and the reference must be that exact rectangle or the guidance points at the wrong pixels.

What it does with the plan

The plan stores, for each of the four views, a core rectangle and a sampling rectangle. The sampling rectangle is the overlap-inclusive one - it's what actually gets evaluated, and it's what TileView crops.

Three things fall out of the source that are worth knowing:

• Two of the four crops come from the top-left origin and two are positioned from the far edge (L - t), which is why the views always cover the canvas even when the extent doesn't divide evenly.
• All four crops come from the same image at the same scale. TileView doesn't resize, tile-batch, or upscale anything.
• The output batch order is image-major: four crops per input image, in plan order. Feed it a batch of three images and you get twelve tiles. The conditioning nodes expect exactly one such group per latent, or one group broadcast across the batch.

Inputs and output

• image - must be exactly the plan's canvas size, in BHWC, RGB or RGBA. Get it wrong and you get an error naming the expected H×W, which is the fastest way to find out that your resize node produced 1088×1472 when the plan wanted 1024×1536. Nothing is padded or stretched for you.
• tile_plan - the one you built for this exact model and canvas.

Output is tiles (IMAGE). Wire it into reference_tiles on either reference node - that's it, one socket.

Install

Same pack, same steps. No dependencies to install and no models to download - the pack is pure Python over ComfyUI's own API, so if the nodes load, they work:

cd ComfyUI/custom_nodes
git clone https://git.colorized.life/tiled-diffusion-ng.git tiled-diffusion-ng
# restart ComfyUI

ComfyUI Manager also has it under Tiled Diffusion NG. You need a reasonably current ComfyUI, since these are V3-API nodes.

When it goes wrong

• Size mismatch. By far the most common failure. Decode a krea-image, upscale it in pixels, then reuse the old plan and TileView throws Expected image H×W ...; received .... Rebuild the plan against the new resolution first; the plan is the source of truth for the crop boxes.
• You expected quadrant-sized tiles. The tiles are larger than the quadrants because they include the overlap. That's not a bug and it's not adjustable here - set tile_overlap on TilePlan if you want to change it. At zero overlap the four crops tile the canvas exactly, and there's nothing to blend.
• You used a look-at-the-crops mindset and then wired it into conditioning. The whole batch goes in, not one tile. The receiving nodes validate the count and will tell you they need four tiles per reference group, or one group to broadcast across the latent batch.
• RGBA survives the crop. If your image has an alpha channel it stays in the batch; the Krea 2 encoder drops it to RGB internally, so this is a non-issue in practice, just don't be surprised by the channel count.

If you want to sanity-check your geometry, this is the node to preview: run TileView into an Image Preview and you should see four rectangles that overlap, in clockwise order, with the top-left crop anchored at the origin. If they don't overlap at all, your tile_overlap didn't reach TilePlan.