Nodes/ComfyUI_EmAySee_CustomNodes/EmAySee_TextEncodeQwenImageEdit_noRS
ComfyUI Node

EmAySee_TextEncodeQwenImageEdit_noRS

The Qwen-Image-Edit text encoder, minus the resolution-selector wiring

By EmAySee·Created about a year ago·Updated 4 months ago· 2
EmAySee_TextEncodeQwenImageEdit_noRS
  • clip
  • vae
  • image
  • CONDITIONING
prompt

Qwen-Image-Edit is the open instruction editor that took over the job masks and ControlNets used to do: hand it a picture plus a sentence and the edit happens - remove an object, swap a garment, re-pose, relight. In ComfyUI that flows through a dedicated text-encode node that packs the edit instruction and the reference image into conditioning. This is a drop-in version of that node with the resolution-selector machinery stripped out - the "noRS" in the name.

Why would you want the no-RS version? The stock Qwen-Image-Edit encoder ships with a resolution selector that picks an internal resolution for the vision encoding. If you're not fighting resolution mismatch (or you're driving resolution from another node in the pack - the repo is full of Qwen resolution-optimizer nodes), the selector is just extra wiring in the middle of your graph. This version cuts straight to the essentials: clip, prompt, optional vae, optional image, conditioning out.

How it works

The mechanism is the same one Qwen-Image-Edit uses natively: the prompt is tokenized with the input image handed to the tokenizer (so the model "sees" the picture as vision tokens), the conditioning is encoded through the CLIP's scheduled-encode path, and - if you supply a VAE - the input image is also VAE-encoded and attached to the conditioning as reference_latents. That reference latent is what tells the model which pixels to keep consistent. No VAE, no reference latent; the text+vision encoding still works, but the edit loses its anchor to the original pixels.

The inputs that matter

  • clip - your Qwen-Image-Edit CLIP model (from the Qwen-Image model pack, not a standard SDXL CLIP - the architecture is different).
  • prompt - the edit instruction, e.g. "remove the hat" or "turn her to face the camera." Multiline, and it supports dynamic prompt syntax.
  • image (optional) - the reference image being edited. Drop it in.
  • vae (optional) - the Qwen-Image VAE; needed to build the reference-latent anchor. Worth wiring in for any actual edit.

The single output is CONDITIONING, which goes into the KSampler's positive input, paired with a matching negative conditioning.

Installing it

Part of ComfyUI_EmAySee_CustomNodes - Manager search for the pack title, or git clone https://github.com/EmAySee/ComfyUI_EmAySee_CustomNodes into custom_nodes/, restart. The pack itself has no extra requirements, but this node is only useful with the actual Qwen-Image model support (the Qwen-Image pack/nodes) installed, and it needs a CLIP model that handles vision input - no model files ship with this repo.

Where people get burned

The whole point of "noRS" is that you own the resolution decision, so if the edit comes out looking off, the first suspect is resolution mismatch between the input image and what the vision encoder expects - the stock node's resolution selector exists for a reason. Also, this node is picky about inputs: without the vae the reference anchor disappears (edits drift, faces move - the documented weakness of Qwen-Image-Edit, per the model's own users), and without image it's just a plain text encode. Wire all three (clip, image, vae) and it behaves like the real thing; leave one out and you get a degraded, occasionally surprising result that looks like the node is broken when it's really just missing its anchor.

Categoryadvanced/conditioning

Inputs (4)

NameTypeDefaultDescription
clipCLIP
promptSTRING
vaeoptVAE
imageoptIMAGE

Outputs (1)

NameTypeDescription
CONDITIONINGCONDITIONING