jz Resize Long Edge (list)
Taming mixed-size batches
- image
- images
- count
ComfyUI's batch tensors are strict: every frame has to be the same size. So the moment you feed it a list of images that aren't - a folder of reference shots, an outpainted sequence, whatever - you hit a wall. jz Resize Long Edge exists to make that a non-problem: it takes a list or batch of mixed-size images and resizes every frame so its longest side equals one target. And critically, it outputs a list, not a batch, so mixed aspect ratios survive the trip.
If you've ever tried to normalize a mixed folder with the stock Image Resize, you know the alternative: you have to know the dimensions up front, which you don't, because they're mixed. This node measures each frame as it goes. Pair it with jz Edge Sizes upstream if you want to derive the target from a reference image instead of typing it.
How it works
The node accepts either a real ComfyUI image LIST (mixed sizes welcome) or a regular batch, unrolls everything into individual frames, and for each one computes the scale factor target / max(width, height) and resizes with LANCZOS. The two knobs you actually set:
- long_edge - the target for the longest side (default 1024, range 16–8192).
- upscale - default on, meaning small images get enlarged up to the target. Turn it off and the node only shrinks images whose long edge exceeds the target, leaving smaller ones untouched. That's the "normalize everything to a max size" mode, and it's the one you want if you're trying to cap memory, not equalize sizes.
The output is a list of images plus a count INT telling you how many frames came out, so downstream "repeat this N times" logic can read the real number instead of guessing.
Why the list output matters
Batches can't hold mixed sizes - that's the whole problem. Lists can. So the node deliberately returns images as a list (is_list: true in its schema), and anything downstream that consumes a list needs to be list-aware. If your next node only takes a batch, you may need a batch-from-list node in between. That's not a bug in this node; it's the fundamental tradeoff of the format, and the author chose the format that doesn't lose data.
Installing it
Same pack, same routine:
cd ComfyUI/custom_nodes
git clone https://github.com/j-zhang19/comfyui-jz
Restart ComfyUI (or Manager → search "comfyui-jz"), find it under jz/image. No models, no GPU requirements; deps are just requests, pillow, numpy.
Common issues
The one that bites: wiring a mixed list into a node that secretly expects a batch. The error usually mentions a shape mismatch, and the fix is either to make your downstream list-aware or to fold everything to a single size first. Second: with upscale on, small images get upscaled to the target - if you expected "only shrink," you're looking at a choice you made, not a bug. And an empty input raises, which is the honest behavior: better a clear error than a silent empty list.
This is a personal-pack utility (solo author, zero community footprint), so the README is the documentation. But the node's behavior is straightforward enough that you won't miss a wiki.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| image | IMAGE | — | |
| long_edge | INT | 102416–8192 | — |
| upscale | BOOLEAN | true | off = only shrink larger images, keep smaller ones |
| interpolationopt | COMBO | lanczos | lanczos is the sharpest but round-trips through 8-bit; area/bicubic/bilinear stay in float |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| images | IMAGE | — |
| count | INT | — |