Eric Qwen Direction Compute

The node that turns "what changed between these two encodings" into a first-class object. Eric Qwen Direction Compute subtracts one conditioning from another:

direction = cond_target − cond_baseline

You encode the same image twice - once with the edit you want more of ("make the person smile warmly"), once as the baseline ("give the person a neutral expression") - and the difference between those two embeddings is the "smile direction". It captures what changes when the instruction changes, in a form you can apply to a different image entirely, at whatever strength you like.

The two inputs

• cond_target - "what you want more of".
• cond_baseline - "what you want to move away from".

That's the whole input side. One direction comes out.

This is the same arithmetic as classifier-free guidance, just with a meaningful reference point. CFG subtracts the empty-string embedding; a direction subtracts a deliberate baseline. Same formula, better anchor.

What you do with it

The output plugs into Direction Apply (to push a base conditioning toward the target), Direction Average or Direction Average From Folder (to debias several single-image directions into a general one), Direction Save (to file it away in models/qwen_directions/), or Direction Inspect (to see spatially where the change lives).

Console output is worth a glance - it prints the peak_token position and RMS, telling you where the direction's energy is most concentrated (usually the face region for expression edits, the whole grid for style).

Building a good direction

Two traps determine whether your direction generalizes:

1. One pair = one image. A direction computed from a single image pair is image-specific. It'll work for that exact photo and drift elsewhere. The fix is averaging several diverse pairs (see Direction Average From Folder) - the shared semantic axis survives, the image-specific noise cancels.
2. Same image vs different image changes what the direction means. Encode the same image twice (different prompts) and the signal lives in the text tokens - that's an expression/attribute direction. Encode two different images (same prompt) and it lives in the image tokens - that's a style direction. Which scope you apply it with later (in Direction Apply) is determined by this.

Installing it

ComfyUI Manager → "Eric Qwen-Edit", or:

cd ComfyUI/custom_nodes
git clone https://github.com/EricRollei/Eric_Qwen_Edit_Experiments.git

Restart. Needs a loaded Qwen-Image-Edit pipeline upstream of the Encode nodes. Model download: Qwen/Qwen-Image-Edit-2511, ~54 GB, plus the pack's own loader node (stock ComfyUI loaders won't work - this pack runs the real diffusers pipeline).

Gotchas

• Nothing to compute if the inputs are identical. Encode same image + same prompt twice and the direction is near-zero. The direction is the difference - make the pair actually differ.
• A direction file is tiny (1–3 MB versus multi-GB LoRAs) and portable across images and sessions. That's the whole point - build once, apply anywhere.
• Directions work without a LoRA for style/tone (film emulation, color grading, lighting). Expression changes are the case that wants a LoRA like PixelSmile, because precise local geometric changes drift otherwise.