Smart Resize & Pad (Black)

If you've run Qwen-Image-Edit on an image that isn't square, you've already met this node's problem, whether you knew it or not. Qwen-Edit doesn't patch your picture - it re-emits the whole frame - and nothing in the architecture pins the pixels you didn't ask about. Feed it an input whose resolution and aspect ratio it isn't expecting, and your "change the background" edit comes back shifted, zoomed, or with proportions subtly wrong. That's the famous offset/unzoom complaint that follows this model around, and it's the same class of problem that makes the KB's resolution lore - keep Qwen input as a controlled size - a thing at all.

CustomSmartResizePad ("Smart Resize & Pad (Black)" in the menu) attacks one clean, common cause: non-square input. It scales your image proportionally to a square canvas and pads the short side with black, so the model always receives a nicely-formed square instead of whatever aspect ratio your source happened to be.

How it works

Peek at the source and it's refreshingly honest - about 40 lines of pure PyTorch, no dependencies. The node resizes the image with bilinear interpolation so the long side lands exactly on target_size, then pads the short side. Portrait images get their padding on the left, landscape images get it on top (the asymmetry matters if you care where the subject ends up). V1 pads with a constant zero - hence the black bars.

It also returns a mask alongside the padded image: white where the original pixels are, black where the padding is. That's the useful half of the output for compositing, because it tells you exactly which pixels are "real" when you wire the result back into the rest of your workflow.

Inputs and outputs

Two inputs, two outputs. That's the whole thing.

• image - the IMAGE tensor you're prepping for the editor.
• target_size - the square canvas size, default 1024, range 64–8192 in steps of 8. 1024 is the pack author's recommendation and a safe default; the community resolution lore for Qwen-Edit is multiples of 112, which the step of 8 happily allows (1008, for instance).

Outputs: padded_image (the square, letterboxed frame) and mask (white = original, black = padding).

Install

It ships in a small pack called ComfyUI-Non-offset by starsFriday (a Qwen-Edit community member - they also publish Qwen-Edit-2509-Upscale2K workflows on HuggingFace). ComfyUI Manager finds it by searching "ComfyUI-Non-offset", or the manual route:

cd ComfyUI/custom_nodes
git clone https://github.com/starsFriday/ComfyUI-Non-offset.git

Restart ComfyUI. No extra packages, no model downloads - requirements.txt literally says none are required. It's just torch, which you already have.

Where people get burned

This node fixes the padding side of the offset problem, not all of it. The KB notes the real fix for Qwen-Edit offset is controlling the resolution the model actually sees - a multiple of 112 - and the standard ComfyUI Qwen-Edit text-encode node has its own opinions about rescaling. So treat this as one tool in that playbook, not a magic bullet: if edits still shift after padding, check what resolution the model is truly receiving.

And the honest catch, which the pack's own README is upfront about: in Qwen-Edit 2509/2511, black borders can themselves cause positional drift - the hard contrast edge and big zero-valued regions mess with attention. That's exactly why there's a V2. If you're on 2511 and black-bar padding leaves you with drift, reach for CustomSmartResizePadV2, which pads with edge pixels instead. Same pack, same inputs, one behavior change, and it's the variant the author recommends.