Painter H3 Size Settings

Two things about MiniMax H3 make size a real problem rather than three numbers you type once. It runs at 24 fps, and its audio-video latent only accepts frame counts sitting on a specific grid - the 17k + 5 ladder: 5, 22, 39, … 124, 141, 158. So "5 seconds" is 124 frames, not 120, and "6 seconds" is 158. Get that wrong and you're either padding or losing frames, and the audio branch has its own opinion about it.

Painter H3 Size Settings is the distilled version of the size subgraph the author was nesting inside his reference-to-video workflow: aspect ratio, resolution, duration in seconds, and out come width, height, num_frames.

What you set

• aspect_ratio - two options, 16:9 (Widescreen) (the default) and 9:16 (Portrait). It doesn't just filter the list, it swaps the resolution menu.
• resolution - nine tiers, 512×288 up through 1920×1088, default 1376×768. Switch to portrait and the same nine tiers appear as their flips, 288×512 up to 1088×1920.
• duration - seconds, default 5, min 0.1, max 120. The little arrows step a full second, but the field is deliberately loosened so a typed 5.1 or 5.3 survives instead of being rounded away.

Which gives you the H3-native values: 5 s → 124 frames, 5.3 s → 141, 6 s → 158, and 15 s → 362, which is right at the top of the range H3 was trained for (roughly 124–362 frames).

The bit that makes it nicer than a calculator

Raw numbers you could type yourself. What you'd forget is the bookkeeping. Portrait isn't a second menu you pick from - the node tracks which tier you were on and flips it, so 1376×768 becomes 768×1376 and you don't get dumped back to the smallest option every time you change orientation. The same flip happens server-side, so a workflow loaded with a mismatched pair (resolution from one aspect, aspect_ratio set to the other) gets corrected rather than producing off-grid dimensions.

And num_frames is computed with the alignment rule baked in: take round(duration × 24), floor it at 5, then bump it up until it lands on 17k + 5. You can't produce an invalid H3 length by accident.

Wiring it up

Three INT outputs, no inputs. width → the width input of your H3 node, height → its height, num_frames → the length input of Painter MiniMax Ref To Video 6. Set size in one place and let the branches fan out; that's the whole value.

The obvious trap: num_frames is H3-shaped, not generic. Feeding it to a Wan 2.2 or LTX graph is asking for off-grid lengths those models don't want - Wan has its own 4n + 1 family of accepted counts. Keep this node in H3 land.

Also, this is a utility frozen from a working subgraph, not a sampler-side optimisation: it doesn't change how the model handles resolution, it just makes sure you ask for something legal. Before you crank to 1920×1088 for a 10-second clip, remember H3 is a 33B model generating picture and audio in one pass - no verified consumer VRAM floor was published at release, and native-audio video models are not the cheap ones to run. The KB's own advice for video holds here: quantise, or pick the resolution tier your card can actually hold.

Installing it

It ships in ComfyUI-PainterNodes, so either search PainterNodes in ComfyUI Manager or:

cd ComfyUI/custom_nodes
git clone https://github.com/princepainter/ComfyUI-PainterNodes

Restart and look under Painter/Utils. The node itself needs nothing beyond Python integers, though the pack as a whole wants soundfile and numpy. One small note for anyone poking at the console: the frontend logs [Painter.H3SizeSettings] on load, which is a quick way to confirm the web extension actually loaded rather than just the Python half.