PixelSmile Conditioning Interpolation

If you've ever sat there typing "happy", "happier", "even happier" into a prompt and squinting at the results, this node is the fix you were looking for. PixelSmileConditioning is the ComfyUI port of the trick behind PixelSmile, the Qwen-Image-Edit LoRA for fine-grained facial expression control that landed on r/StableDiffusion in early 2026. Instead of fighting wording, it blends two text conditionings - a neutral one and a target expression - in embedding space, and gives you a single score dial for how much of the expression comes through. Set 0 and you get the neutral read, set 1 and you get the full target, go past 1 and the expression overshoots.

The honest framing first: this pack is tiny and ships no model. It's one node that does math on CONDITIONING tensors. The actual PixelSmile magic - the LoRA trained with symmetric contrastive learning on Qwen-Image-Edit - lives over at Ammmob/PixelSmile on GitHub and HuggingFace. judian17's port just contributes the intensity-slider mechanism, and the original project's README links it as the official community ComfyUI implementation. Install this alone and nothing happens; install it inside a Qwen Image Edit workflow and you get expression control nobody else was offering.

How it works

The mechanism is embarrassingly simple, which is why it works. You feed it two conditionings from a Qwen text encoder - conditioning_target ("Edit the person to show a happy expression") and conditioning_neutral ("...a neutral expression"). For every token embedding it computes:

result = neutral + score * (target − neutral)

That's a straight linear interpolation in conditioning space, score_one_all style. The score_one method is cleverer: it only interpolates the last 7 tokens, on the theory that the expression words sit at the end of the prompt. Short prompts fall back to the global blend. Under the hood the code also pads the two sequences to the same length (Qwen's encoder doesn't always produce matching token counts), interpolates pooled_output if the model uses it, and fixes up the attention mask. Nothing exotic, and because it never touches a sampler or a model directly, it's cheap - this runs in milliseconds.

The inputs that matter

Three of the four inputs are worth touching:

• conditioning_target / conditioning_neutral - the two CLIPTextEncode (or TextEncodeQwenImageEditPlus) outputs. The neutral one is your anchor; the target is the expression you're dialing toward.
• score - the whole point of the node. Range 0–3, default 1. 0 is pure neutral, 1 is full target, anything above 1 pushes past the target and starts producing exaggerated faces. Start around 0.5–1; the bundled workflow opens at 0.
• method - score_one_all (default, interpolate everything) vs score_one (only the tail tokens). If your expression word isn't at the end of the prompt, score_one will do nothing useful - use score_one_all.

The single CONDITIONING output wires straight into the sampler's positive input, right where you'd put any other conditioning.

Installing it

cd ComfyUI/custom_nodes
git clone https://github.com/judian17/ComfyUI-PixelSmile-Conditioning-Interpolation

Restart ComfyUI (or grab it from ComfyUI Manager - search "PixelSmile"). The node itself has zero Python dependencies beyond torch, which ComfyUI already ships.

The bundled workflow at workflow/qwen_image_edit_with_pixelsmile.json is the real install cost. It needs the Qwen2.5-VL-7B-Instruct GGUF clip (a ~6 GB download via ComfyUI-GGUF), a Flux-class UNet, a flux VAE, and PixelSmile-preview.safetensors from the PixelSmile HuggingFace repo. Good news: TextEncodeQwenImageEditPlus is built into recent ComfyUI core, so that part's free.

Where people get burned

The classic trap: expecting the node to carry the whole feature. It doesn't - the LoRA and the Qwen stack do the heavy lifting, and the node is the fine control on top. Also watch the overshoot: score >1 extrapolates outside the embeddings the model saw during training, and past ~2 you start getting uncanny grimaces rather than "more happy". Dial, don't crank.

One honest caveat: the author states the code was generated by Gemini and the repo is a hobby-grade port. For a node that does one math operation, that's fine - the logic is readable and correct. Just don't expect a thriving issue tracker. It's the kind of thing you grab, wire into your Qwen edit workflow, and never think about again.