H3 Image Reference

H3's reference-to-video (Ref2VA) mode is the reason people are finally excited about local video generation - the reaction in the community when it landed was basically "we can dump images, audio, and video as references now, no more generating a start frame and training a LoRA to lock the character." H3 Image Reference (TuringUtilsH3ImageReference) is the node that encodes your reference images for that path. You give it images; it gives you a image_reference object that feeds both the Qwen semantic stage and the DiT conditioning stage.

The design philosophy is refreshing: it refuses to destroy your references. No blind crop-to-square, no upscale-to-model-resolution. It resizes only when it has to and only down, and it leaves your composition alone otherwise.

Inputs that matter

• vae (VAE, required) - the H3 video VAE. Each reference becomes a [1,24,1,H,W] latent.
• megapixels (FLOAT, default 1.0, range 0.1–16) - the cap on source area when no latent is connected. The author's tooltip says it plainly: "Maximum source area when latent is not connected; smaller images are not enlarged." Bigger images get scaled down toward this budget; smaller ones are left alone.
• latent (LATENT, optional) - if connected, sizing switches to match-area mode: references are resized to the decoded area of that latent.
• images (autogrow, up to 32) - the reference images themselves. These come in as image_1, image_2, … sockets that you add as needed.

Output: image_reference (TURING_UTILS_H3_IMAGE_REFERENCE) → H3 Semantic Reference and H3 Build Conditioning.

How it actually works

For each image it computes a scale factor: match the latent's area if one is connected, otherwise cap at megapixels * 1,000,000 pixels. The scale is clamped to 1.0, which is the "never upscale" guarantee. Then it does a lanczos resize to 32px-aligned dimensions and runs each one through the VAE. That's it. Your 512×768 character sheet stays roughly 512×768 in spirit; it's not being forced into a 1024×1024 square it was never meant to fill.

One honest caveat: those 32 up to slots are tempting, but every reference costs VRAM as a latent and costs Qwen tokens in the semantic stage. Start with two or three. H3 is generous with references; your memory is not.

The megapixels vs. latent rule, in one line

Connect a latent and you're telling the node "size references to match this target." Don't connect one and megapixels is the governor. If you're doing a straight text-to-video-with-references, the default 1.0 MP is a sane place to start - low-res refs staying low-res is usually what you want, since H3's DiT reads them at their encoded resolution.

Installing it

From the ComfyUI Turing Utils pack (repo wjie98/comfyui-svdint4; the README still references the old comfyui-turing-utils name). ComfyUI Manager, search "svdint4" or "Turing Utils":

cd ComfyUI/custom_nodes
git clone https://github.com/wjie98/comfyui-svdint4

Restart ComfyUI, done. requirements.txt is only safetensors; the CUDA kernel build (python -m pip install -v --no-build-isolation -e ./kernel) is a separate step you'll want for running H3, but this node - a VAE encode - runs without it.

Where it sits in the graph

Images in → H3 Image Reference → image_reference → both H3 Semantic Reference (Qwen "looks" at the images for the prompt) and H3 Build Conditioning (the DiT gets the encoded latents). That two-wire pattern - semantic + structural - is the pack's core design, and it's what lets you re-encode images at one resolution and reuse the semantic pass at another without paying for Qwen twice.