CPA TileGuide
Feeding LTX one 1920×1088 tile instead of the whole 4K frame
- images
- positive
- negative
- vae
- latent
- positive
- negative
- latent
CPA TileGuide is the adapter between "I have a 4K plate" and "the model only understands 1080p". It crops one native-resolution tile out of the plate, pads it into a legal LTX chunk, and runs it through the IC-LoRA guide node so a subsequent sampling pass is steered by that tile's pixels.
That last sentence is the whole v14 native-resolution-edges feature in miniature. The plate is matted on a 1080p proxy; then, only along the subject's edge, the pack renders the same alpha again at native resolution and merges the strands back in. TileGuide is what makes each of those tile passes possible.
Why a guide, not just a bigger render
An IC-LoRA guide is how LTX-2.5's alpha-gen works at all: you hand it a video and it produces alpha for that video. The guide's frames are what the model conditions on. So the honest way to get 4K edges is to give it 4K pixels - but the model is trained and tuned around 1920×1088, and handing it a 3840×2160 frame is not a thing you want to do.
The pack's answer is tiles: 1920×1088 crops, at least 50% overlap, only the ones that touch the subject's edge on any frame. Those go through this node, one LTX pass each, and get feather-merged afterwards. More single strands, each thinner, instead of a 1080p edge scaled up.
Inputs
Position and time first. x, y, width, height are the tile rectangle in the native plate; start, length and end are the chunk's place in the sequence - length is the chunk size, end a stop frame (any negative value means "don't stop early"). images is the native plate, not the proxy.
Then the sampling context: positive, negative, vae, latent, and latent_downscale_factor, all passed through to ComfyUI's LTXAddVideoICLoRAGuide. The outputs are the same three, positive, negative, latent, now holding the tile as their guide. Wire them into the sampler and you get a tile-sized alpha chunk out the other end.
The padding is where the fiddly details live, and they're the same ones the rest of the pack uses: the tile's height and width are rounded up to a multiple of 32 by edge replication, and if the chunk is short of length frames the last frame is repeated. Both are LTX's requirements, and doing it here means every tile pass lines up with every other one and with the proxy passes.
Under the hood the guide call uses frame_idx=0, strength=1.0, cropping disabled and tiled encoding off, matching the 1080p passes. That consistency is deliberate - a tile that conditions differently from the proxy pass produces a tile that disagrees with it, which is the one thing the merge step can't repair.
The dependency that bites
It calls LTXAddVideoICLoRAGuide from ComfyUI itself, and if that node isn't there it raises the most useful error in the pack: "Native-resolution edges need ComfyUI's LTXAddVideoICLoRAGuide node: update ComfyUI (or switch native-resolution edges off)." It also checks that the node still returns three outputs and tells you to report it if a future ComfyUI changes that. Given how often ComfyUI reshuffles LTX nodes, that's the right kind of defensive.
This is a genuine reason to keep ComfyUI current beyond habit. An out-of-date install won't fail politely on the generator - it'll fail in the middle of a 4K render, after the proxy pass has already burned nine minutes.
Install
Part of the pack, plus the two node packs the whole thing needs:
cd ComfyUI/custom_nodes
git clone https://github.com/rik-python/ComfyUI-Comfy-Pro-Alpha-Generator.git
pip install -r ComfyUI-Comfy-Pro-Alpha-Generator/requirements.txt
Install ComfyUI-LTXVideo and ComfyUI-SAM3 via Manager, accept the gated Lightricks licences, and make sure ltx-2.5-video-vae-conv-bf16.safetensors is in models/vae/ - the conv VAE specifically, since only that one can encode the guide. ComfyUI 0.38 or newer. Non-commercial licence on the pack itself.
Should you wire it by hand?
No. It's hidden from the node menu and the pack's native-edges stage expands into one of these per tile at run time - it can't know which tiles it needs until SAM3 has tracked your subject, so the graph is built during execution. Its real value to you is diagnostic: if you see native edges: N of M tiles at 3840x2160 in the console, this node is about to run N times, and that number is why the render takes 58 minutes instead of 19.
Inputs (13)
| Name | Type | Default | Description |
|---|---|---|---|
| images | IMAGE | — | |
| x | INT | 0 | — |
| y | INT | 0 | — |
| width | INT | 1920 | — |
| height | INT | 1088 | — |
| start | INT | 0 | — |
| length | INT | 49 | — |
| end | INT | -1 | — |
| positive | CONDITIONING | — | |
| negative | CONDITIONING | — | |
| vae | VAE | — | |
| latent | LATENT | — | |
| latent_downscale_factor | FLOAT | 1.00 | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| positive | CONDITIONING | — |
| negative | CONDITIONING | — |
| latent | LATENT | — |