LockPixel Apply Reference
Already Have a Latent? This Node Hands It to Qwen-Edit as the Reference
- conditioning
- latent
- conditioning
Most of the LockPixel pack exists so you never have to think about reference_latents at all. LockPixelApplyReference is the exception: a small manual override that takes a conditioning and a latent you already have, and stamps that latent in as Qwen-Edit's reference image. It's the node you reach for when the pack's normal path doesn't fit your graph, not the one you start with.
Qwen-Image-Edit conditions on its input image twice - once through a vision-language encoder for understanding, once as a latent through the VAE for spatial appearance. The second part travels inside the conditioning object as a reference_latents entry, and this is exactly where alignment drift gets born: if the reference latent and the latent you hand the sampler are on different grids, the model re-emits the frame slightly offset. LockPixelApplyReference is a blunt, useful tool for that specific slot.
What it does
Two inputs, one output, zero options. It takes a conditioning (CONDITIONING) and a latent (LATENT), then uses ComfyUI's node_helpers.conditioning_set_values to append that latent's samples as the reference_latents key on the conditioning. Out comes a new conditioning you can feed straight into a sampler. That's the whole node - the same mechanism the standard TextEncodeQwenImageEditPlus uses internally, except you get to supply the latent instead of letting the text encoder build one.
When would you actually use it? The classic case: you've built a conditioning some other way and you want to bolt your own reference on top - a VAE-encoded crop from an inpaint workflow, a latent you saved from an earlier stage, a reference that wasn't produced by this pack at all. Think of it as the "take my latent, please" port.
The one gotcha
This node sets the latents but not the reference_latents_method. In the sibling LockPixelQwenEncode node, a qwen_2511 flag is what sets reference_latents_method: index_timestep_zero, which the 2511 checkpoint expects to see. If you're wiring ApplyReference manually on a 2511 build, keep that in mind - the reference gets attached either way, but you may want the same conditioning metadata the encoder node would have added. For the common 2509 path it's a non-issue.
Install and context
LockPixelApplyReference ships in tori29umai0123/ComfyUI-QwenImageEdit-LockPixel, a zero-dependency pack (no requirements.txt - just ComfyUI's own node_helpers). Install once, use all four nodes:
cd ComfyUI/custom_nodes
git clone https://github.com/tori29umai0123/ComfyUI-QwenImageEdit-LockPixel
then restart ComfyUI and find the nodes under qwen image edit/lockpixel. If you run ComfyUI Manager, search "LockPixel" instead.
One honest caveat from the pack's own README: none of this makes unedited pixels identical, because VAE encode/decode is lossy. LockPixel fixes the grid mismatch; if you need pixel-perfect untouched regions, composite the output back over the original with a mask after generation.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| conditioning | CONDITIONING | — | |
| latent | LATENT | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| conditioning | CONDITIONING | — |