TextEncodeQwenImageEditPlusCustom lrzjason

This is the deep end of the pack, and it's honest about it. Where Advance and Pro give you a fixed set of image slots with shared settings, Custom takes a list of per-image configs - so image A can be a 1024px padded VAE reference while image B is a 512px center-cropped VL-only input with its own mask. If your workflow has grown to the point where "all images treated the same" stopped being true, this is where you go. If it hasn't, use Pro; this node is genuinely more setup for genuinely more control.

It's the v2.0 centerpiece of the pack, added alongside the config-builder and extractor nodes that only exist to feed and unpack it. Think of it as the engine, and QwenEditConfigPreparer / QwenEditConfigJsonParser / QwenEditOutputExtractor as the intake and exhaust.

How it works

Qwen-Image-Edit reads every input through two paths - Qwen2.5-VL for semantics, the VAE for appearance - and this node lets each image declare, individually, how it wants to be handled on both paths. A config carries things like to_ref (send this image to the VAE reference pass), ref_main_image (is this the subject), ref_longest_edge, ref_crop, to_vl (include it in the semantic pass), vl_resize, vl_target_size, and an optional per-image mask. You build those configs upstream, chain them into a list, and this node consumes the whole list at once, producing conditioning plus a fat output dictionary with every intermediate result inside it.

The mask support (added in v2.0.5) is the interesting part given where Qwen edit is weak. Qwen re-emits the whole frame, so unmasked regions drift; a per-image region-of-interest mask is how you nudge it back toward touching only what you meant.

The inputs and outputs that matter

Required: clip, vae, prompt, and configs (the list - build it with QwenEditConfigPreparer or QwenEditConfigJsonParser). The two optionals:

• return_full_refs_cond - default true. True gives you conditioning with all reference latents; false gives you conditioning with only the main reference. This just sets which one lands on the primary conditioning output.
• instruction - the system prompt; ships with a working default.

Outputs are deliberately lean: conditioning (into KSampler positive), latent (into latent_image), and custom_output - an ANY dictionary holding everything: pad_info, the full-refs and main-ref conditionings, the main image, the lists of VAE images / reference latents / VL images, the assembled full_prompt, the llama_template, and the mask. You don't read that dict directly - you pipe it into QwenEditOutputExtractor, which breaks it into named sockets.

Installing it

ComfyUI Manager, search Comfyui-QwenEditUtils, install, restart - or clone https://github.com/lrzjason/Comfyui-QwenEditUtils into ComfyUI/custom_nodes and restart. No extra pip deps or bundled models; you supply the Qwen-Image-Edit checkpoint, Qwen2.5-VL encoder, and VAE. The repo ships two example workflows - qwen edit custom.json and qwen edit custom mask.json - and honestly, loading those is the fastest way to understand this node.

Common issues

The number-one mistake is not building the configs list at all - configs is required, and without a QwenEditConfigPreparer (or JsonParser) feeding it, the node has nothing to do. After that: exactly one config should be flagged as the main reference; flag zero and the main-ref conditioning is empty, flag several and you're gambling on which wins. Because this is the most-moving-parts node in the pack, it's also the most exposed to the version-scaling drift the pack is known for - build against one version and stay on it. And remember the pack's own README now nudges you toward its successor, ComfyUI-EditUtils; the Custom node still works, but the frontier moved.