Shrink Image (Soze)

Exactly what the name promises - it makes an image smaller, and it's honest about being a one-way street. The scale input caps at 1.0, so this isn't the node to reach for if you're trying to upscale; grab a dedicated upscaler for that. What you do get is a straightforward downscaler with two ways to specify the target size and an actual choice of resampling algorithm, which a lot of quick-and-dirty resize nodes skip.

How it works

mode picks between scale (a multiplier off the original size, 0.01 to 1.0) and pixels (explicit width/height targets). maintain_aspect locks the aspect ratio when true, so in pixels mode you're really only setting the dimension that governs and letting the other follow proportionally.

resize_algorithm is the part worth understanding rather than leaving on default: LANCZOS (the default) is the sharpest general-purpose choice and the right pick for photographic content. BICUBIC is a reasonable, faster middle ground. BILINEAR is softer and faster still. NEAREST is blocky by design - no interpolation at all - which is exactly what you want for pixel art or for resizing a hard-edge mask where you don't want new gray fuzz introduced at the boundary.

The inputs and outputs that matter

• image - what you're shrinking.
• mode - scale or pixels.
• resize_algorithm - see above; LANCZOS is the safe default.
• maintain_aspect - keep the original proportions.
• scale (used in scale mode) - 0.01 to 1.0, default 0.5.
• width / height (used in pixels mode) - explicit target dimensions.

Outputs are the resized IMAGE plus a status string, useful for confirming the actual dimensions a batch run landed on without popping a preview open every time.

Installing it

ComfyUI Manager: search ComfyUI_Soze. Manual: cd ComfyUI/custom_nodes && git clone https://github.com/SozeInc/ComfyUI_Soze.git, pip install -r ComfyUI_Soze/requirements.txt, restart. Standard image processing - no models, no extra dependencies.

Common issues

The most common trip-up is trying to use this for upscaling and finding scale simply won't go past 1.0 - that's by design, not a bug. Beyond that, this is a pre-processing step, not a magic fix: pre-shrinking an oversized phone photo before it hits a sampler will save you VRAM, but if you're trying to hit a strict size limit for an API upload (this pack's own Veo3.1 or ComfyDeploy nodes, for instance), pair it with pixels mode and explicit numbers rather than relying on scale, since scale's output size depends on whatever the source image happened to be.

One more thing worth flagging on resize_algorithm: it's easy to leave every image node in a workflow on whatever its default is and never think about it again, but this is one of the places that default actually matters. LANCZOS looks noticeably better than BILINEAR on anything with fine detail or text, and the cost difference is negligible at the resolutions this node is typically used at - pre-shrinking before a sampler, not doing final output work - so there's rarely a good reason to drop below it unless you're deliberately going for the blocky NEAREST look.