LockPixel Pad Image

Padding is the boring kind of fix, and it's exactly what Qwen-Image-Edit needs. When you edit with Qwen, the model re-emits the whole frame, and if the reference latent and the sampler latent get built at different sizes you get visible drift - small shifts, subtle zoom, pixels that weren't asked to move. LockPixelPadImage avoids the worst of it by doing something almost aggressively simple: it pads your image out to a clean multiple of 32 without resizing a single pixel, and records what it did so the rest of the pipeline can undo it later.

The trick of the pack is that the reference and the sampler should share one latent grid. Pad the input once, encode it once with the VAE, and hand that same latent to both Qwen's reference_latents and the KSampler's latent_image. Qwen's internal 1MP reference resize is one of the classic drift sources - by never resizing, just padding, you sidestep that whole path.

The inputs that matter

• image (IMAGE) - your input, padded on the right and bottom only. Top-left stays anchored so nothing shifts.
• multiple (INT, default 32, range 8–256, step 8) - the grid size to pad to. 32 is the author's tested default and what the example workflow uses; you can drop to 16 if you're experimenting, but 32 is the safe answer.
• pad_mode - replicate (default), reflect, or constant. This decides what the new border pixels look like:
  • replicate copies the edge pixels outward - the no-fuss default for photos.
  • reflect mirrors the image - cleaner seams, but it needs the source bigger than the pad. If it isn't, the node quietly falls back to replicate, so you won't error out, just get a different border.
  • constant fills with a flat value - which is where constant_value (FLOAT, 0.0–1.0) comes in. For manga and lineart work a white fill (1.0) is often the right call; black (0.0) for dark scenes.
• constant_value (FLOAT, default 0.0) - only matters when pad_mode is constant.

Outputs

Two of them. image is the padded tensor, ready for LockPixelQwenEncode. lockpixel_info is the metadata object (original size, padded size, exact pad amounts) that LockPixelCropBack consumes after decode to return you to the original dimensions. Keep those two wires paired - that info object is meaningless if it gets mismatched with a different image.

If your image is already a multiple of 32, the node adds nothing and still hands back valid info, so you can leave it in the graph unconditionally.

Where it sits

Load Image -> LockPixelPadImage -> LockPixelQwenEncode -> KSampler
                                  LockPixelPadImage -> (lockpixel_info) -> LockPixelCropBack

Install is light - the pack has no requirements.txt, just ComfyUI's own node_helpers:

cd ComfyUI/custom_nodes
git clone https://github.com/tori29umai0123/ComfyUI-QwenImageEdit-LockPixel

Restart ComfyUI and the nodes appear under qwen image edit/lockpixel (or install via ComfyUI Manager, search "LockPixel"). The author, tori29umai, is the same person behind the Qwen-Edit lineart extraction LoRA, and this padding scheme is his documented approach to the shifting-pixels problem made into a node. One honest caveat: padding fixes the grid, not the pixels - VAE encode/decode is lossy, so untouched regions come back close but not identical. If that matters, mask the original back over the result after generation.