CineTimeline｜原生尺寸

It looks like a reroute. It's a validated constant.

CineNativeResolution has two INT widgets and two INT outputs, and it returns the numbers you gave it. If that sounds like nothing, you're half right - but it's the node that keeps the rest of a delivery graph honest about what size the shot actually is.

The setup it belongs to: H3 works on a strict pixel grid. The pack's own numbers say H3 needs dimensions aligned to a 32-pixel grid, and the author's example of a 1.5x RTX pass on an 864×480 render lands at 1312×736 - precisely because the target got snapped to that grid rather than to whatever 1.5× arithmetic suggested. New seven-node workflows in this pack either normalise delivery to a standard 1280×720 with center fit, or explicitly keep the internal size. This node is the second half of that choice: instead of letting a scale node, an upscaler output size, or a delivery normaliser quietly decide, you state the native width and height once, in one place, and feed that value wherever a size is needed.

The guard is the value

width defaults to 1296 and height to 720, both with a step of 16 and a range of 16 to 16384. Run it and it checks that both are positive multiples of 16; if not, it stops with H3 dimensions must be positive multiples of 16.

The step on the widget nudges you in the UI. The check is what protects you from everything that isn't the UI: a saved workflow from an older graph, an API prompt with a hand-typed size, or another node computing a dimension and handing it over. In a pipeline where a bad size doesn't crash anything - it just quietly resamples your shot or produces a plausible-but-wrong render - an explicit raise is worth two widgets.

Same for the outputs. width and height come out as INTs and go into the size inputs of whatever you're driving: the delivery-size stage, an upscaler you want pinned to a specific target, a postprocess branch. It gives you exactly one place to change the number when you change your mind.

What it won't do for you

Two things people expect and don't get.

It does not make the render native to your shot. Pinning 1296×720 into a chain whose segment was rendered at 864×480 gives you a scale-up, politely labelled. The value has to match what the H3 pass actually produced.

And it doesn't make a big render feasible. H3 is 33B with a 32B text encoder; VRAM scales with resolution and frame count, and this is a family where a 5-second clip at 864×480 on 20 steps measured around 71 seconds end-to-end on the author's hardware while a 15-second one took nearly six minutes. A node that validates multiples of 16 is not going to save you from that - quantisation, step count and the 8-step distill path are what do. Treat the resolution question as "what can I afford to render", and this node as the place you record the answer.

Installing it

It ships in the pack with everything else - no dependencies of its own, no models. Manager search CineTimeline, or:

cd ComfyUI/custom_nodes
git clone https://github.com/bo341805sg/ComfyUI-CineTimeline
# restart ComfyUI, hard-refresh the browser

One environment note that applies to the whole pack: the author's verified setup is Windows, ComfyUI 0.30.0, with the paired INT8 ConvRot H3 checkpoints, which require launching with --disable-dynamic-vram. The loader refuses INT8 weights when DynamicVRAM is still enabled, and it refuses INT8 mixed with NVFP4. If resolution isn't the thing that's biting you, that probably is.