Nodes/ComfyUI-EditUtils/EditUtils: Longest Edge Image Process lrzjason
ComfyUI Node

EditUtils: Longest Edge Image Process lrzjason

Resize-and-pad your reference the way EditUtils does — without burning a CLIP encode

By lrzjason·Created 7 months ago·Updated 16 days ago· 207
EditUtils: Longest Edge Image Process lrzjason
  • image
  • processed_image
  • pad_info
  • scale_by
ref_longest_edge1024
ref_croppad
ref_upscalelanczos
vae_unit8

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.

Categoryimage

Inputs (5)

NameTypeDefaultDescription
imageIMAGE
ref_longest_edgeINT10248–4096Longest edge of the output image
ref_cropCOMBOpadCrop method: pad adds padding, center crops to center, disabled keeps as-is
ref_upscaleCOMBOlanczosUpscale method
vae_unitINT88–64VAE unit size for padding alignment

Outputs (3)

NameTypeDescription
processed_imageIMAGE
pad_infoANY
scale_byFLOAT