Zura · Pack H3 Control Latents

If you've ever looked at H3's fun-control model patch and wondered what it wants on the input side, the answer is "a 49-channel latent, assembled by hand." This node assembles it. It's the boring middle of the control chain and it's where every shape error eventually lands.

What it's the middle of

Three visible steps, deliberately:

1. Zura · Prepare H3 Control Pixels → fitted_control, masked_source, visibility.
2. Stock VAEEncode ×2 → depth latent, masked-source latent. The pack says outright that the graph must use stock VAEEncode nodes here; it does not hide an encode inside itself.
3. This node → one 49-channel latent.
4. Zura · Apply Encoded H3 Control → patched MODEL.

Splitting it this way is a design choice with a cost: more wires to get wrong. The benefit is that the encodes are visible and the expensive middle artifact is cacheable and inspectable rather than a black box.

Where 49 comes from

torch.cat of three things along the channel axis:

• 24 channels - the encoded depth guide (control_latent).
• 1 channel - the visibility mask, trilinearly interpolated down from pixel space to latent space.
• 24 channels - the encoded masked source (masked_source_latent).

24 + 1 + 24 = 49. Depth tells the model what the geometry should be, visibility tells it where it's allowed to change things, and the masked source gives it the original pixels everywhere else. That last channel exists so the sampler has real content to preserve rather than a flat average.

Before concatenating, the node checks that both encodes match the target latent's shape exactly, and that visibility is genuinely binary - the code rejects anything that isn't 0 or 1 outright - and sits at the exact native pixel raster with the exact frame count the target latent implies. The frame count comes from H3's own arithmetic: ((tokens - 2) / 5) * 17 + 5.

The visibility channel is what gets interpolated rather than the mask, which matters: you're handing the model a soft-edged allowance to edit, not a hard key.

Inputs and outputs

• control_latent - LATENT, 24 channels, stock-encoded depth guide.
• masked_source_latent - LATENT, 24 channels, stock-encoded masked source.
• visibility - MASK, binary, pixel raster, from Prepare H3 Control Pixels.
• target_latent - LATENT, the H3 target latent whose shape everything is measured against.
• prepared_control - LATENT, 49 channels, into Apply Encoded H3 Control.

Install

cd ComfyUI/custom_nodes && git clone https://github.com/ZURAVFX/ComfyUI_zura_nodes
pip install -r ComfyUI_zura_nodes/requirements.txt

Restart. You need the H3 base weights, the H3 video VAE (for both stock encodes), the text encoder, and minimax_h3_fun_controlnet_union_2.0_pruned_int8_convrot.safetensors in models/model_patches/. That last one isn't bundled - none of the weights are. H3's licence restricts where the weights may be used; check that before you commit disk space.

Common issues

"Both stock H3 VAE encodes must exactly match the target video shape." Almost always a resolution mismatch: you encoded at a nice round 1920×1080 while the target latent implies a multiple of 32. Feed fitted_control and masked_source - the outputs of the prepare node - straight into the encodes and don't resize between them.

"Visibility must be the fitted binary mask at the exact native pixel raster and length." You passed the original edit mask rather than the visibility output. They're inverses of each other, and the node only accepts the fitted one.

"Prepared H3 control exceeds the 256 MiB payload limit." A long clip at high resolution. 49 channels is a lot of latent - trim the take or work at the native H3 resolution instead of upscaling first.

Order confusion. control_latent is the depth guide; masked_source_latent is the source with the edit area knocked out. They're both 24 channels, they'll both typecheck in either socket, and swapping them produces a plausible-looking graph that generates rubbish. Worth double-checking once.