TextEncodeQwenImageEditPlusAdvance lrzjason
Split control over Qwen's two image reads
- clip
- vae
- vl_resize_image1
- vl_resize_image2
- vl_resize_image3
- not_resize_image1
- not_resize_image2
- not_resize_image3
- conditioning_with_full_ref
- latent
- target_image1
- target_image2
- target_image3
- vl_resized_image1
- vl_resized_image2
- vl_resized_image3
- conditioning_with_first_ref
- pad_info
This is the node you reach for when the stock Qwen edit encoder is too blunt and you don't want to build a full config pipeline. Its trick is that it lets you control Qwen-Image-Edit's two image reads separately - which images get resized for the vision-language pass, which get sent to the VAE untouched, and at what target sizes. If you've ever gotten a Qwen edit that came back slightly the wrong shape, this node's resolution controls are the fix.
Some background on why that split matters. Qwen-Image-Edit reads your input twice: once through Qwen2.5-VL (the semantic "what is this" pass, which wants a small ~384px image) and once through the VAE encoder (the appearance pass, which wants a larger ~1024px+ latent). Cram the same image through both at the same size and you're compromising one of them. This node stops making you compromise.
How it works
You get two families of image inputs. The vl_resize_image1/2/3 slots are the pictures you want the VL side to see, resized down to the VL target size. The not_resize_image1/2/3 slots go into processing without that VL resize step - for images you've already sized, or that you want handled differently. The node then encodes the prompt with all that visual context and, given a VAE, produces the reference latent to sample from.
The reason this matters beyond tidiness: Qwen edit re-emits the whole frame, so getting the input geometry right is the difference between a clean edit and one where every pixel drifted. Controlling the VAE target size (and cropping vs padding to reach it) is exactly the lever the community uses to beat the offset problem.
The inputs and outputs that matter
Required: clip and prompt. The ones you'll actually set:
- target_size - the VAE-side resolution: 1024 / 1344 / 1536 / 2048 / 768 / 512, default 1024. This is your quality/VRAM dial. 1536 gets you the ~2.3MP edits people show off; 2048 if you have the headroom.
- target_vl_size - the vision-language size, 384 or 392, default 384. Leave it at 384 unless you have a reason.
- crop_method -
pad,center, ordisabled.padpreserves the whole image by padding to the target (and is what feeds the pad_info output);centercrops to fill. - upscale_method -
lanczos/bicubic/area; lanczos is the sharp default. - instruction - the system prompt that tells Qwen how to reason about the edit. It ships with a sensible default; rewrite it only if you know what you want.
Outputs worth knowing: conditioning_with_full_ref (the conditioning carrying every reference image - this is your main KSampler positive), latent (into latent_image), target_image1/2/3 and vl_resized_image1/2/3 (the processed versions of what you fed in, for compositing or inspection), conditioning_with_first_ref (conditioning built from only the first reference, for a more focused edit), and pad_info (an ANY dictionary of scale/pad values - hand it to CropWithPadInfo to crop the result back to your original content area).
Installing it
ComfyUI Manager: search Comfyui-QwenEditUtils, install, restart. Or cd ComfyUI/custom_nodes && git clone https://github.com/lrzjason/Comfyui-QwenEditUtils then restart. Nothing to pip-install, nothing bundled. As always with this pack, the node is just the conditioning layer - you supply the Qwen-Image-Edit checkpoint, its Qwen2.5-VL text encoder, and the Qwen-Image VAE yourself (GGUF or fp8 on consumer cards, plus a Lightning LoRA for sane speeds).
Common issues
The output-name discrepancy trips people: the README calls the main output "CONDITIONING," but on the node it's conditioning_with_full_ref, and there's a second conditioning_with_first_ref - grab the right one or your edit either sees too much or too little reference. Version drift is the other landmine: image scaling has changed across releases (a workflow tuned on 1.1.1 won't reproduce byte-for-byte on 1.1.7), so pin a version once you're happy. And if edits still come back misaligned or blurred, that's the resolution issue - push target_size to a value the model likes and use pad so nothing gets cropped away; that's the whole reason the pad_info plumbing exists.
Inputs (14)
| Name | Type | Default | Description |
|---|---|---|---|
| clip | CLIP | — | |
| prompt | STRING | — | |
| vaeopt | VAE | — | |
| vl_resize_image1opt | IMAGE | — | |
| vl_resize_image2opt | IMAGE | — | |
| vl_resize_image3opt | IMAGE | — | |
| not_resize_image1opt | IMAGE | — | |
| not_resize_image2opt | IMAGE | — | |
| not_resize_image3opt | IMAGE | — | |
| target_sizeopt | COMBO | 1024 | 6 options: 1024, 1344, 1536, 2048, 768, 512 |
| target_vl_sizeopt | COMBO | 384 | 2 options: 392, 384 |
| upscale_methodopt | COMBO | 3 options: lanczos, bicubic, area | |
| crop_methodopt | COMBO | 3 options: pad, center, disabled | |
| instructionopt | STRING | Describe the key features of the input image (color, shape, size, texture, objects, background), then explain how the user's text instruction should alter or modify the image. Generate a new image that meets the user's requirements while maintaining consistency with the original input where appropriate. | — |
Outputs (10)
| Name | Type | Description |
|---|---|---|
| conditioning_with_full_ref | CONDITIONING | — |
| latent | LATENT | — |
| target_image1 | IMAGE | — |
| target_image2 | IMAGE | — |
| target_image3 | IMAGE | — |
| vl_resized_image1 | IMAGE | — |
| vl_resized_image2 | IMAGE | — |
| vl_resized_image3 | IMAGE | — |
| conditioning_with_first_ref | CONDITIONING | — |
| pad_info | ANY | — |