LockPixel Crop Back
Cutting Qwen-Edit's Borders Back Off After Decode
- image
- lockpixel_info
- image
LockPixelCropBack is the cleanup step of the pack - the node that slices the padding off after the VAE has done its thing, so you get back exactly the image size you started with. It does one job, does it with two inputs and one output, and if you're running the standard LockPixel workflow you can't really skip it.
Here's the deal with the whole pack: Qwen-Image-Edit drifts when the reference latent and the sampler latent land on different grids, so the pack pads your image up to a multiple of 32 and encodes that padded image once, using the same latent for both jobs. That leaves you with a decoded image that has extra border pixels on the right and bottom. LockPixelCropBack is what removes them.
How it works
The node takes an image (IMAGE, straight out of a VAEDecode) and a lockpixel_info (LOCKPIXEL_INFO), and returns the cropped image. The magic isn't in the crop - it's in the info: lockpixel_info is a small metadata object carrying the original height and width plus the exact padding amounts, recorded when LockPixelPadImage did the padding. CropBack reads orig_height and orig_width from it and slices the image down to that size, cutting the bottom and right borders away.
That's why the two nodes are a matched pair. The lockpixel_info you feed in here must come from the same LockPixelPadImage that padded the image you're decoding - don't swap wires from a different branch, or you'll crop to the wrong dimensions. Wire it as a parallel connection alongside the image path:
LockPixelPadImage (image) -> LockPixelQwenEncode -> KSampler -> VAEDecode -> LockPixelCropBack (image)
LockPixelPadImage (lockpixel_info) ----------------------------> LockPixelCropBack (lockpixel_info)
Notes and gotchas
- Padding is only added to the right and bottom, never the top and left. That's deliberate - it keeps the top-left corner anchored so nothing visually shifts, which is the whole point of the exercise.
- If you padded with a different node (or by hand),
lockpixel_infowon't match and the crop will be wrong. UseLockPixelPadImagefor the info, or skip CropBack and trim manually. - On images that are already a multiple of 32,
LockPixelPadImageadds nothing, and CropBack becomes a harmless no-op that still returns a valid image. - The honest limit, per the README: cropping fixes the frame and the grid mismatch, but VAE encode/decode is lossy, so unedited regions come back near-identical rather than pixel-identical. If strict preservation matters, mask-composite the output over the original after generation.
Install is one line from the pack repo (no extra Python deps, so no requirements.txt dance):
cd ComfyUI/custom_nodes
git clone https://github.com/tori29umai0123/ComfyUI-QwenImageEdit-LockPixel
Restart ComfyUI and the nodes live under qwen image edit/lockpixel (or search "LockPixel" in ComfyUI Manager). Like its siblings, this is a small, purpose-built node from the author who'd been documenting Qwen-Edit's shifting-pixels problem in the community - and CropBack is the tidy ending to the fix.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| image | IMAGE | — | |
| lockpixel_info | LOCKPIXEL_INFO | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| image | IMAGE | — |