MiniMax H3 R42 · Exact LTX Delivery Size
Your LTX upscale gave you the processing canvas, not the delivery size. This fixes that
- images
- cine_linx
- images
- report
Latent upscalers are picky about canvas sizes. LTX's would rather work on a legal multiple-of-32-ish grid, so when you ask for a 2048×1080 delivery it may hand you back a 2208×1152 frame instead - technically a successful upscale, and quietly the wrong aspect ratio for anything downstream.
IAMCCS_MiniMaxH3ExactLTXDeliverySizeR42 is the adapter that closes that gap. The old R42 delivery group only knew about the processing canvas, so its internal "exact delivery size" step was comparing against the wrong target. This node sits after the LTX decode, reads the authored delivery size out of the Shotboard plan, and makes the frames match it.
Inputs and outputs
Two required inputs, nothing optional:
images- the decoded frame batch from the LTX stage.cine_linx- the context wire. This is where the authored target lives (target_width/target_heightin the upscale settings, falling back to the plan's upscale dimensions, with a floor of 256px).
Outputs are images (now at the authored size) and report, which records the journey: protected size, the crop it took, and the final size.
What it actually does
It refuses to distort your frame. Rather than stretching 2208×1152 into 2048×1080, it centre-crops to the target aspect ratio first, then resizes with bicubic interpolation with antialiasing - so you get a clean geometric result and no anamorphic squeeze.
The resize runs four frames at a time and moves each slice to float32 for the interpolation, then returns it at the source dtype and device. That matters on long clips: the naive version needs another full float32 copy of the whole programme in memory at the peak, and on a 600-frame delivery that's the difference between finishing and OOM-ing in the last thirty seconds of the run.
There's one branch that returns your frames untouched, deliberately. If the ltx_4k flag is set in the upscale settings and the delivery route is one of the master routes, the node defers to the RTX 4K path, because that node owns its own final exact-size pass - and running two resamples back to back would soften the image for nothing. The report says deferred to RTX 4K so you know which route took it.
The trap worth knowing
Centre-crop means edges. You lose a sliver of the long side to get the aspect right, and it's taken symmetrically. If you're rendering to an unusual delivery ratio - a scope crop, a vertical format - set the target size in Shotboard so the processing canvas is close to it, and give yourself headroom for the crop. The alternative is framing a shot, then discovering the delivery pass ate four percent of each side.
Install
cd ComfyUI/custom_nodes
git clone https://github.com/IAMCCS/IAMCCS-nodes.git
Or Manager → IAMCCS, restart. Nothing to download for this node on its own. It's part of the R42 universal delivery chain, so the heavy requirements belong to the stages around it: the H3 model plus its video and audio VAEs, and whatever upscaler route you selected (LTX latent upscaler, or the RTX VSR path for 4K). If you're wiring this by hand rather than using the pack's delivery group, put it immediately after the LTX decode and before anything that cares about aspect ratio - a WAN-style video combine, an RTX pass, or a save with resizing off.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| images | IMAGE | — | |
| cine_linx | IAMCCS_SUPERNODE_LINX | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| images | IMAGE | — |
| report | STRING | — |