TextEncodeQwenImageEditPlus_NoAppend

Qwen-Image-Edit-2511 doesn't take a plain prompt like an SD checkpoint. Your instruction goes through the model's CLIP together with the reference images, wrapped in a chat template - which is what the stock TextEncodeQwenImageEditPlus node does, up to a point. This node is the pack's variant of that encoder, and the "NoAppend" in the name is the point: it encodes exactly the prompt you type, without the reference-image boilerplate the stock node sneaks in after your text.

How it works

You hand it a clip (the Qwen-Image-Edit CLIP), your prompt, and up to three images. It does three things under the hood:

• Resizes each image to 384×384 for the vision-language branch of the CLIP - that's the part that lets the model actually see what you're referring to.
• If you pass a vae, it also encodes the images to ~1024² reference latents, which carry the low-level appearance into the sampler. No VAE, no reference latents, and appearance control gets weaker - so feed the VAE.
• Tokenizes Picture 1: <|vision_start|>…<|vision_end|> plus your text inside Qwen's standard instruction template, and returns a single CONDITIONING for the sampler.

The naming matters if you've used the stock node. The official one appends reference-image framing to your user prompt; this variant skips that and sets the reference latents with append=False, so the model reads your words as the whole instruction. That's a deliberate choice for the RefineAnything workflow, where the prompt is a tight "refine the masked region" style command and extra framing just dilutes it.

The inputs that matter

• clip - the Qwen-Image-Edit-2511 CLIP, loaded via a CLIPLoader with the matching file. Don't swap in the base Qwen-Image clip; the edit model's encoder is what understands the image tokens.
• prompt - your instruction, multiline. For refinement work the model's own card suggests prompts starting with "refine" behave best (e.g. "refine the text on the label so it reads clearly"), and the LoRA also shows some grounding ability for add/remove/modify even without dedicated training.
• vae - optional but practically required for good appearance control, since it produces the reference latents.
• image1 / image2 / image3 - the reference images, numbered. In the RefineAnything workflow these are wired from RefineAnything_PreImg: the cropped region as image1, the binary mask as image2. In reference-image mode the README's rule is: reference image goes to image2 and the reference mask to image3.

Output is a single CONDITIONING that feeds your sampler's positive. In the example workflow it runs through a ConditioningZeroOut to produce the negative as well.

Installing

Part of the same pack, no separate install - ComfyUI Manager search for ComfyUI_RefineAnything, or:

cd ComfyUI/custom_nodes
git clone https://github.com/smthemex/ComfyUI_RefineAnything

Restart. Dependencies are just ComfyUI's own (einops, torch, PIL), so there's no pip step. The setup cost is all models: the Qwen-Image-Edit-2511-RefineAny.safetensors LoRA from the limuloo1999/RefineAnything Hugging Face repo, the Qwen-Image-Edit-2511 diffusion model + CLIP + VAE, and ideally the 4-step Lightning LoRA so you can run the example's four-step KSampler. On consumer VRAM that means a GGUF quant of the 20B model.

Troubleshooting

• "No reference latents" behavior. If the result ignores what's in the images, check the vae is connected - without it this node degrades to text-only conditioning.
• Edits drift or the model changes what you didn't ask about. That's the model's whole-frame re-emission habit, and this pack's crop-then-paste design exists to contain it. Keep the mask tight in RefineAnything_PreImg.
• Conditioning looks different from the stock node's output. It is - that's the feature. If your prompt was written for the stock node's appended framing, add the context yourself ("the image shows…") rather than expecting this one to.