TextEncodeQwenImageEditPlus lrzjason

If you're doing Qwen-Image-Edit work in ComfyUI and you've hit the wall where the stock encoder only takes three reference images, this is the node you came looking for. TextEncodeQwenImageEditPlus_lrzjason is a drop-in replacement for ComfyUI's built-in TextEncodeQwenImageEditPlus that pushes the reference-image count up to five and hands you real control over how those images get resized before they're fed to the model. Same job, more room, more knobs.

That extra room matters more than it sounds. Qwen-Image-Edit's whole trick since the 2509 revision is composing multiple inputs, person plus product, person plus scene, subject plus a clean background plate, and the stock node caps you at three. People genuinely run out: batching or stitching extra images into one tensor as a workaround is a common move, and it makes the results wobble. This node just gives you the extra slots.

What it actually does

It's the text-encode stage of a Qwen edit graph, and the reason it's not just a prompt box is that Qwen-Image-Edit reads your reference images two completely different ways at once. Each image goes into the Qwen2.5-VL vision-language encoder for semantic understanding ("what is this a picture of"), and separately into the VAE for appearance ("these exact pixels"). This node does both passes, at different resolutions, then packs the resulting reference latents into the conditioning it emits. That dual encoding is exactly why one model can both nudge colors and recompose a whole scene, and it's why the encoder is doing real work rather than string concatenation.

By default it prepares each image at roughly 1024px for the VAE side and 384px for the vision-language side. You don't have to think about those numbers to get a result, but they're the levers if a result comes out soft or oddly proportioned.

The inputs and outputs that matter

Two inputs are required: clip (the Qwen2.5-VL text encoder, loaded through a CLIP loader) and prompt, your plain-language edit instruction. "Change her jacket to red leather," "remove the person on the left," that kind of thing.

For editing you also want vae connected. It's marked optional, but the VAE is what turns your reference images into the latents the edit rides on, so skip it and you've thrown away the point. Then image1 through image5 are your references; wire in as many as you need. The handful of tuning inputs worth knowing:

• enable_resize / enable_vl_resize (both on by default) toggle the automatic 1024/384 resizing. Leave them on unless you're deliberately controlling size upstream.
• crop (center or disabled) and upscale_method (lanczos, bicubic, area) decide how images are fit. lanczos is the sane default.
• instruction is a system-prompt template that tells the model how to read the image and apply your edit. It ships with a sensible default; ignore it until you have a reason not to.

Outputs: conditioning goes to your KSampler's positive slot, and latent (the encoded first reference image) goes to the sampler's latent_image input. The image1–image5 outputs hand back each processed reference so you can preview exactly what got fed in, which is genuinely useful for debugging.

Installing it

ComfyUI Manager is the easy path: open Manager, search Comfyui-QwenEditUtils, install, restart. By hand:

cd ComfyUI/custom_nodes
git clone https://github.com/lrzjason/Comfyui-QwenEditUtils

then restart ComfyUI fully. The node itself has no heavy Python dependencies, but it's useless without the Qwen-Image-Edit model stack behind it: the diffusion weights, the Qwen2.5-VL text encoder, and the VAE. That's a 20B model, so on consumer hardware you'll be running a community GGUF quant plus a Lightning/8-step speed LoRA rather than the full bf16, that's the normal setup, not a compromise. One heads-up from the author: this repo has been succeeded by ComfyUI-EditUtils, which folds in Flux2Klein support. QwenEditUtils still works fine for Qwen-only work.

Where people get burned

The big one isn't the node, it's the model. Qwen-Image-Edit re-emits the entire frame rather than patching the pixels you asked about, so unedited areas come back close but not identical, and that drift compounds across a chain of edits. There's also a known geometric offset that skews proportions unless you keep input resolution under control, which is exactly what the resize inputs here are for. If you need a region truly untouched, mask it and composite the edit back rather than trusting the whole frame to hold still.

Two smaller traps. Make sure clip is the Qwen2.5-VL encoder, not an SDXL or Flux CLIP, a mismatched encoder is the most common "why is my output garbage" cause. And keep your node, workflow, and model revision aligned: mixing a 2511-era model with a workflow built for an older encoder throws cryptic tensor-size errors at encode time. When something breaks here, it's almost always a version mismatch, not the node.