Nodes/ComfyUI-EditUtils/EditUtils: Crop With Pad Info lrzjason
ComfyUI Node

EditUtils: Crop With Pad Info lrzjason

Deliver Edits at the Original Size, Not With Black Bars

By lrzjason·Created 7 months ago·Updated 16 days ago· 207
EditUtils: Crop With Pad Info lrzjason
  • pad_info
  • image
  • cropped_image
  • scale_by

EditUtils workflows scale your references up, pad them to a VAE-friendly grid, and only then encode them. That's great for the model - dimensions land on clean multiples of the VAE unit and nothing gets cropped off - but it means the image coming out of the sampler is letterboxed. CropWithPadInfo_EditUtils is the node that takes the image back to its original content area. It's the "undo" half of the pad round-trip, and once you need it, you need it constantly.

The interface is tiny: pad_info (ANY) and image in; cropped_image (IMAGE) and scale_by (FLOAT) out. The mechanism is a straightforward read of the padding dictionary: pad_info carries the width and height of the padding that was added (plus x/y placement and the scale_by factor). The node subtracts that padding from the image dimensions and crops the right/bottom bars off, giving you back the original content area - then hands you scale_by so you know how much the image was resized in the first place, which is exactly the number you need if you want to restore the true original resolution downstream.

Where does pad_info come from? The pad_info output on EditTextEncode_EditUtils, or the pad_info output on Flux2KleinOutputExtractor_EditUtils. The repo's own "Simple Krea 2 Depth" workflow shows the exact wiring: EditTextEncode_EditUtils's pad_info and main_image both feed CropWithPadInfo_EditUtils after the VAEDecode, then straight into SaveImage. As long as the pad info and the image come from the same encode, the crop is exact - the source code computes the original content dimensions as image − padding and slices precisely that region.

The ordering matters, so here's the actual flow: encode → sample → VAEDecodeCropWithPadInfo → save. If you crop before sampling you've thrown away the padding the model was conditioned on and the results will look off. Keep the pad through the whole generation, then crop at the end as a pure post-process. That's the pattern every workflow in this pack assumes, and it's the single most common place beginners break an EditUtils graph - cropping too early or forgetting the round-trip entirely and shipping images with black bars.

Two honest caveats. pad_info only exists when the crop mode was pad; if you ran with ref_crop: "center" there's nothing to undo and no pad_info to feed in. And the node is trusting - it reads whatever dict you hand it, so feeding it a pad_info from a different image than the one in the image socket produces garbage geometry rather than an error. Keep the pair together. Install: ComfyUI Manager (search "EditUtils") or git clone https://github.com/lrzjason/ComfyUI-EditUtils into custom_nodes, restart. No models, no dependencies.

Categoryimage

Inputs (2)

NameTypeDefaultDescription
pad_infoANY
imageIMAGE

Outputs (2)

NameTypeDescription
cropped_imageIMAGE
scale_byFLOAT