ImageTransformResizeRelative
The 'make it twice as big' node — resize by multiplier, not pixel math
- images
- IMAGE
Most resize nodes in ComfyUI want a pixel count: "make it 1024 wide." ImageTransformResizeRelative is the one that wants a multiplier instead. Set scale_width to 2.0 and the width doubles; 0.5 halves it. You never compute the target resolution - the node does that from whatever image lands on its input.
That sounds like a small convenience until you're resizing inside a loop. Most resizing you actually do is relative anyway: an img2img pass at half the base resolution, a compositing step at 1.5x, an upscale-then-back for a preview. And because it's a ratio, one node handles a whole batch of animation frames regardless of how their source sizes differ. It's the resize node you reach for when the answer to "how big?" is "2x," not "1042 by 832."
How it works
Allor's transform nodes operate on tensors but hand the actual pixel work to PIL. Each frame in the batch gets converted to a PIL image, resized, and converted back into the B×H×W×C tensor ComfyUI expects, then re-stacked. The relative variant reads the width and height from the first image in the batch, multiplies each by your scale factor, floors to an integer with int(), and resizes every frame to that single target.
One gotcha hides in there: because the target size comes from frame one, feeding it a batch of mixed-resolution images normalizes them all to one size. Usually that's exactly what you want; occasionally it's a surprise. And the int() floor means 0.5 on a 511px-wide image gives you 255, not 255.5 - irrelevant at normal sizes, mildly annoying if you're doing pixel-perfect tiling.
The method dropdown offers the six PIL resamplers: lanczos, bicubic, hamming, bilinear, box, nearest. Lanczos is the default and right for most work. Remember this is pure interpolation - same family as the "more pixels, nothing invented" path the community falls back to when a generative upscaler is the wrong tool. It adds no detail, and it won't fix a blurry image. Nearest is your pixel-art friend; box is handy for aggressive downsizing.
The inputs that matter
images- the IMAGE batch to scale (required)scale_width,scale_height- FLOAT, default 1.0 (a no-op), step 0.1. 2.0 doubles, 0.5 halves, 1.5 adds 50%.method- the resampling filter, defaultlanczos
The single output is IMAGE, same batch size as the input. It wires straight into anything that takes an image: a KSampler for img2img, VAEEncode, a detailer, a SaveImage.
Installing Allor
ImageTransformResizeRelative lives in the Allor Plugin, Nourepide's ~90-node image-processing pack. Easiest path is ComfyUI Manager - search "Allor." Otherwise:
cd ComfyUI/custom_nodes
git clone https://github.com/Nourepide/ComfyUI-Allor
Restart ComfyUI. First run generates a config.json in the pack folder, and the pack's own install.sh / install.bat will install requirements into your venv or embedded Python. Dependencies are rembg and onnx (plus onnxruntime, which rembg drags along) - heavier than a resize node needs, because the pack also ships background-removal nodes. This node never touches them.
Common issues
The pack's real pain point is updates. The repo was rebased to strip images from its history, and the README itself warns this can break auto-updates; on the ground, users report Allor nodes silently vanishing after an update. If that happens, a fresh re-clone is the reliable fix - or set "update_frequency": "never" in config.json and update on your own terms.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| images | IMAGE | — | |
| scale_width | FLOAT | 1.0 | — |
| scale_height | FLOAT | 1.0 | — |
| method | COMBO | 6 options: lanczos, bicubic, hamming, bilinear, box, nearest |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| IMAGE | IMAGE | — |