APNext H3 Resolution (1344x768 = 1.0 MP)

Every H3 render you've ever seen at 16:9 was 1344×768. That's not a coincidence - it's the vendor's adapt_canvas rule, and it's the exact recipe H3 was trained on. H3ResolutionSelector exists to hand that recipe back to you per aspect ratio, instead of letting you guess a resolution and hoping the model copes. It's the node that answers "what size do I render at" with something that isn't a vibes-based answer.

Why a resolution node needs to exist at all

ComfyUI core's Resolution Selector counts megapixels from 1 MP = 1024². H3 doesn't. The vendor's rule is: scale so the short edge is 768, cap the area at 1344×768, round every side to a multiple of 32. That yields 95 trained canvases - and it means aspects do not share a pixel count. 16:9 lands on 1344×768 (1008 tokens/frame), while 1:1 is 768×768 (576 tokens/frame - about a third of 16:9's attention cost). Hand H3 a square 1024×1024 because that's "1 MP" and you're feeding it an off-distribution canvas no released pipeline ever produced. This node's megapixels 1.0 is the trained frame for the aspect you picked, and the dropdown labels tell you exactly what each shape resolves to.

Inputs and outputs

• aspect_ratio - 11 presets, each labelled with the trained canvas it gives: 16:9 widescreen - the trained canvas (1344x768), 1:1 square - a third of 16:9's attention cost (768x768), 21:9 ultrawide (1536x672), and the portrait and photo variants. Squarer is cheaper - worth remembering when you're budgeting a long render.
• megapixels (default 1.0) - canvas scale. 1.0 is the exact vendor recipe; leave it there for real renders. Below 1.0 shrinks the area for cheap previews; above 1.0 exceeds the vendor's area cap, which no released H3 pipeline ever does.
• multiple (default 32) - the grid every side must sit on. H3 needs 32; 128 additionally aligns the token grid for Morton-ordered sparse attention.
• frames (default 192) - target frame count, snapped up onto H3's 17n+5 frame grid. 192 is exactly 8.000 s at 24 fps, the only common integer duration on the grid; the trained range is 124–362. 0 skips the report.

Outputs: width and height wire straight into the render node's width/height; frames into its length; duration_seconds into a writer's duration_seconds; megapixels is the real count (1344×768 = 1.03); and info is a one-line report of canvas, tokens/frame, attention cost versus 16:9, snapped length and total video tokens.

The bits that matter in practice

The frame snapping is the quiet star. H3's VAE only accepts lengths on the 17n+5 grid, so "192 frames" renders clean but "185" doesn't - this node rounds up for you and tells you what it landed on. And the info output is genuinely useful for budgeting: it reports the video token count so you can see why a 16:9 render costs three times a 1:1 of the same duration.

It's a drop-in for core's Resolution Selector - same width/height outputs - so swapping one for the other takes seconds.

Installing

Part of the dagthomas pack - ComfyUI Manager, search "comfyui_dagthomas", install, restart:

cd ComfyUI/custom_nodes
git clone https://github.com/dagthomas/comfyui_dagthomas
cd comfyui_dagthomas
pip install -r requirements.txt

No models, no extra dependencies, pure math on the widget values. It's the rare node you can add to any H3 workflow without touching the queue time at all - which is exactly why it's worth having around even on workflows that already "work."