TextEncodeQwenImageEdit lrzjason

This is the plain one. Before you touch the Plus/Advance/Pro variants with their five image slots and pad dictionaries, this node is the honest starting point: one reference image, a prompt, and the conditioning that Qwen-Image-Edit needs to do its thing. If you're editing a single picture with a sentence - "change her dress to blue," "remove the watermark," "put him in an ice cave" - this is all you actually need from the pack.

It exists because Qwen-Image-Edit doesn't work like a normal text-to-image model. Qwen's editor is Apache-2.0, uncensored, and it won the open-editing category from Flux Kontext largely on licensing - which is why the community built a whole tooling layer on top of it. The catch is that the model reads your image twice, through two different doors, and something has to prepare the image for both doors. That's this node.

How it works

Qwen-Image-Edit dual-encodes the input. The image goes into a Qwen2.5-VL vision-language model for visual semantic control (what's in the picture, understood as concepts) and, separately, into the VAE encoder for visual appearance control (the actual pixels, as a reference latent). One path tells the model what it's looking at; the other gives it the texture to preserve. This node runs both: it feeds your prompt plus the image through the CLIP side and, if you hand it a VAE, encodes the image into the reference latent the sampler starts from.

That dual read is also why Qwen edit is fiddly about resolution - feed it an awkward size and the output comes back subtly offset or blurred. The enable_resize and resolution controls are here to keep you on a size the model likes.

The inputs and outputs that matter

Required is just clip and prompt. Everything else is optional but you'll want it:

• image - the picture you're editing. Skip it and you're doing plain text-to-image with a Qwen edit encoder, which is not the point.
• vae - provide it and you get a real reference LATENT out; without it, no latent to sample into.
• resolution - the target longest edge, choose from 2048 / 1536 / 1328 / 1024 / 768 / 512, default 1024. Note 1328, not 1344, on this node. Higher = more detail and more VRAM.
• enable_resize - on by default; leave it on unless you've already sized the image yourself upstream.

Outputs are CONDITIONING, IMAGE, and LATENT. Wire the conditioning into your KSampler's positive slot, the latent into its latent_image input, and use the IMAGE output if you want the resized version the node actually fed the model (handy for compositing the result back later).

Installing it

ComfyUI Manager is the easy path: search Comfyui-QwenEditUtils, install, restart. Or from a terminal, cd ComfyUI/custom_nodes && git clone https://github.com/lrzjason/Comfyui-QwenEditUtils and restart. No requirements.txt to fight and nothing bundled - the nodes land under advanced/conditioning.

What the pack does not give you is the model. This node is useless without the Qwen-Image-Edit stack loaded elsewhere in the graph: the Edit checkpoint (2509 or 2511, almost always a GGUF or fp8 quant on a consumer card), its Qwen2.5-VL text encoder, and the Qwen-Image VAE - usually plus an 8-step Lightning LoRA so a single edit takes seconds instead of a minute. People run the whole thing on 8GB of VRAM with a GGUF build; the bf16 20B weights are not a consumer-card proposition.

Common issues

The recurring one across this pack: version drift. The way images get scaled has changed between releases, so a workflow saved on an older version can produce visibly different framing after an update - worth pinning a version if you've dialed something in. If your edit comes back shifted or soft, that's the classic Qwen offset problem, and it's a resolution issue - control the input size (that's what resolution is for) and it lines up. And note the repo itself now points you at its successor, ComfyUI-EditUtils, which folds in Flux2Klein alongside Qwen; this pack still works fine, but that's where the author's attention went.