EditUtils: Longest Edge Image Process lrzjason
Resize-and-pad your reference the way EditUtils does — without burning a CLIP encode
- image
- processed_image
- pad_info
- scale_by
The EditUtils pipeline has a specific way of treating reference images: scale so the longest edge hits a target (default 1024), then pad or crop to an even multiple of the VAE's spatial unit (8 for Qwen, 16 for Flux2Klein). It does this inside the encode node, which is fine - except when all you want is the preprocessing. LongestEdgeImageProcess_EditUtils extracts exactly that resize-and-pad logic into a standalone node, no CLIP, no VAE, no conditioning. Pure pixels in, processed pixels out.
The inputs are the same knobs the encode path uses: image, ref_longest_edge (default 1024, the "Longest edge of the output image"), ref_crop (pad / center / disabled), ref_upscale (lanczos / bicubic / area), and vae_unit (default 8). Outputs are processed_image, pad_info (a dict with the padding amounts and scale factor), and scale_by (a FLOAT, the scale ratio).
Where it shines is consistency. If you want to feed the same preprocessed image into something else - a ControlNet, an IP-Adapter, a second model that isn't part of the EditUtils encode chain - this node gives you the exact representation the main pipeline would produce, so nothing drifts. The other classic use: inspect what your reference is actually going to look like after padding, before you commit a 20B edit model to it. And because pad_info records how much black border was added, you can undo it later with the pack's CropWithPadInfo_EditUtils, which slices the padding back off and returns the original content area plus its scale factor.
Quick mechanism note: with ref_crop="pad", it upscales to the target longest edge, then centers the result on a black canvas rounded up to the vae_unit multiple - that canvas is what keeps VAE encoding clean, because the VAE dislikes dimensions it wasn't trained on. The pad_info dict captures exactly how much border went where. That's the same black-padding behavior the encode node uses for its main image, which is why outputs line up.
Install
Part of lrzjason/ComfyUI-EditUtils. Manager → search "ComfyUI-EditUtils", or git clone https://github.com/lrzjason/ComfyUI-EditUtils into custom_nodes and restart. No pip deps, no models bundled.
Troubleshooting
Two things to know. First, scale_by in the output is the reciprocal of the raw scale (it's rounded to 3 decimals) - if you're using it to reverse the resize, that's deliberate, but don't confuse it with the upscale factor you typed. Second, pad_info is only meaningful when ref_crop="pad"; with center or disabled there's no black border, so feeding the resulting pad_info into CropWithPadInfo is a no-op at best. If your padded image looks wrong for vae_unit=8 when you're actually running Flux2Klein, flip it to 16 - matching the model's VAE unit is the whole alignment trick.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| image | IMAGE | — | |
| ref_longest_edge | INT | 10248–4096 | Longest edge of the output image |
| ref_crop | COMBO | pad | Crop method: pad adds padding, center crops to center, disabled keeps as-is |
| ref_upscale | COMBO | lanczos | Upscale method |
| vae_unit | INT | 88–64 | VAE unit size for padding alignment |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| processed_image | IMAGE | — |
| pad_info | ANY | — |
| scale_by | FLOAT | — |