Qwen2.5-VL Encode Condition

This is the pack's second "image → CONDITIONING" node, and here's the thing you need to know up front: it is functionally identical to the Qwen2.5-VL Clip Encoder. Same inputs, same output, and if you diff the two classes in the source they're the same code under different names - same vision-embedding model file, same resize, same mean-pooling, same [[tensor, {}]] conditioning wrapper. That's what happens when a pack is assembled by an author leaning on LLMs for the plumbing: you get two nodes that solve the same problem, and whichever you add to your graph, you're getting the other one too.

None of which makes it useless. In a pack aimed at Intel CPU/iGPU laptops, this is the lightweight member - it never loads the Qwen language model, just the vision tower from openvino_vision_embeddings_model.xml, so a single image forward pass is all it costs. That's the whole pitch: image features as a cheap reference vector, no GPU required.

How it works

Your image is resized to the model's input size (read from the compiled model's partial shape, defaulting to 224×224 when it can't be determined), normalized to 0–1, transposed to channel-first, and run through the OpenVINO-compiled vision tower. The output feature map gets mean-pooled over its spatial axes into one vector, converted to a float tensor, and returned as a ComfyUI conditioning pair. Same as the Clip Encoder node, down to the error message when openvino_vision_embeddings_model.xml is missing from the model folder.

The caveat that matters

Because that vector is a vision embedding, not a text encoding, nothing guarantees it lines up with your sampler's cross-attention. Real conditioning comes from a text encoder matched to the diffusion model; this is a vision tower's raw output with no remapping. It can drive a custom graph where you control the mapping, and it's a cheap way to probe whether Qwen's image features are useful for whatever you're building. Feeding it straight into a vanilla SD/SDXL KSampler is a gamble - dimension mismatch or garbage output is the likely outcome. It's a "features" node wearing a "conditioning" costume.

Inputs and output

• image - any IMAGE tensor; resized internally to the model input size.
• model_path / device - the pack defaults: the auto-downloaded helenai/Qwen2.5-VL-7B-Instruct-ov-int4 repo id and CPU. "GPU" is Intel iGPU, not NVIDIA.

One CONDITIONING output, wireable anywhere a conditioning plugs in.

Install & troubleshooting

Install through ComfyUI Manager (search ComfyUI-Qwen2.5-VL-7B-OPENVINO) or by cloning https://github.com/blackmeat1225/ComfyUI-Qwen2.5-VL-7B-OPENVINO into custom_nodes/ and running pip install openvino-genai pillow in a fresh venv (the repo ships no requirements.txt - the README's manual install is the real one, and the clone URL printed there is stale). The first queue run downloads the multi-gigabyte model into models/openvino/.

Common failure: pointing model_path at a folder that lacks openvino_vision_embeddings_model.xml - this node raises a clear FileNotFoundError rather than degrading gracefully. And since it shares a model cache with its Clip Encoder twin, if you've already loaded one, the other loads instantly. Honestly, if you only need single-image features, pick either name and ignore the sibling - the only real difference is the label.