Nodes/H3 LBH X2 Stream/H3 LBH Shared Image Conditioning
ComfyUI Node

H3 LBH Shared Image Conditioning

What H3 LBH Shared Image Conditioning buys you

By sepiablue-ai·Created 22 days ago·Updated 16 days ago· 4
H3 LBH Shared Image Conditioning
  • clip
  • vae
  • first_frame
  • low_positive
  • high_positive
  • low_latent
◄prompt—►
◄low_width384►
◄low_height672►
◄high_width544►
◄high_height960►
◄length243►

A two-pass video workflow has an annoying structural problem: you need conditioning for the low-resolution pass and for the high-resolution finish, and the naive build encodes the prompt twice and VAE-encodes the start frame twice. H3 LBH Shared Image Conditioning collapses that into one node with three outputs, one text-encoder pass, and two keyframe latents - one per resolution.

The word "shared" is doing real work. Text encoding on an LLM-encoder model is a whole separate model load and a slow pass - the encoder is its own budget, not a footnote to the diffusion model - so doing it once instead of twice is genuinely worth a node.

How it works

You feed it a first frame and one prompt. It fits that image to the high target with a centred crop (ImageOps.fit with Lanczos), fits it again to the low target, tokenizes the prompt once with the high-res image attached, and encodes. Then it VAE-encodes both fitted frames and attaches each one as frame-0 minimax_keyframes on its own copy of that single conditioning. Finally it allocates an empty audio-video latent at the low dimensions, with length frames.

So the three outputs are a matched pair plus a canvas:

  • low_positive → the first BasicGuider. Same prompt, keyframe at 384×672, matches the latent you're sampling into.
  • low_latent → SamplerCustomAdvanced as the latent input. Empty; the low pass fills it.
  • high_positive → the second BasicGuider, downstream of the upscale. Same prompt, keyframe at 544×960.

Why two keyframes and not just reuse the low one? Because the keyframe you condition on is at the resolution you're sampling at. Handing a 384×672 latent keyframe to a 544×960 pass is the kind of mismatch that doesn't error, it just quietly conditions worse.

The fields you actually touch

clip, vae, first_frame and prompt are the wiring. The prompt box is multiline and supports dynamic-prompt syntax. The five integers are the four sizes plus length: low_width/low_height (384×672), high_width/high_height (544×960), length 243 stepping by 17 from a floor of 5 - the shipped presets land on 124, 243 and 345 frames at 24fps for the 5s, 10s and 14s examples.

Two things about those sizes are worth internalising, because people get them backwards. high_width/high_height is the last sampling resolution, not the output resolution. The final 1088×1920 comes from the X2 VAE stage doubling 544×960. And the lift from low to high isn't 2× - it's 384×672 → 544×960, about 1.42×. The "2×" in the pack name lives at the very end.

Install

Manager: search H3 LBH X2 Stream, install, restart; add the sibling H3 X2 Stream if you want the shipped examples to run end to end. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/sepiablue-ai/ComfyUI-H3-LBH-X2-Stream

then restart. Python deps are just einops and safetensors; CUDA/PyTorch come from ComfyUI. The node imports H3's native YAML/CLIP path (minimax type in CLIPLoader) and _empty_av_latent from core comfy_extras, so an older ComfyUI will fail at import - the author validated against 0.38.0/0.39.0. Sample inputs are not copied by Manager; the three example images need to go into ComfyUI/input/ yourself.

Common issues

Your framing changes between passes. The fit is a centred aspect crop, so a tall portrait shot into a landscape target loses the sides - and it loses them differently at 384×672 than at 544×960 if the two aspect ratios differ. Keep both pairs at the same aspect ratio or your first frame isn't the same crop in both passes. The example pairs are 4:7 and 17:30, close enough not to notice.

Small drift in the finished video. This node is first-image (I2VA) conditioning only. The repo is explicit that the presets derive from an FL2VA model but ship no final-frame conditioning, so the tail is wherever the model takes it.

"Conditioning shape" errors downstream. That's odd spatial condition latents hitting the DiT. The pack's answer is the sibling pad node placed at the end of the model chain - see the pack's H3 LBH Pad Visual Conditions. What you check here is that all four dimensions are multiples of 32.

Length doesn't match the preset. Set the frame count here and only here. The handoff node rebuilds the high-res latent from the low one, so there's no second place to change it, and a length that disagrees with your sigma split just gives you a shorter or longer clip than you planned.

CategoryH3 LBH X2 Stream

Inputs (9)

NameTypeDefaultDescription
clipCLIP—
vaeVAE—
first_frameIMAGE—
promptSTRING—
low_widthINT38432–8192—
low_heightINT67232–8192—
high_widthINT54432–8192—
high_heightINT96032–8192—
lengthINT2435–3600—

Outputs (3)

NameTypeDescription
low_positiveCONDITIONING—
high_positiveCONDITIONING—
low_latentLATENT—