HB Outpaint Padding

The name is doing a lot of heavy lifting here. HB Outpaint Padding doesn't outpaint a single pixel - it computes four numbers. What it's good at is answering the question everyone hits when they first try to extend an image: how much do I pad each side? Give it an image and a target size, and it hands back the left, right, top, and bottom padding needed to reach that aspect ratio, split symmetrically so your subject stays centered. Then you feed those numbers into the node that actually pads the canvas.

What it actually computes

Three inputs: image, target_width (default 1920), and target_height (default 1080). The outputs are four INTs - left, right, top, bottom - and the logic in the source is short and legible. It reads the image's height and width, compares your current aspect ratio to the target, and pads only the axis where you're short. If your image is narrower than the target ratio, it computes the width needed to match, splits the difference with left = total // 2 and the remainder on the right. If it's too wide, same deal for top/bottom. If the ratios already match, you get 0, 0, 0, 0.

That last point is the gotcha people walk into: this node pads to the ratio, not to an absolute pixel count, and it never upscales. Feed a 512×512 image in with a 1920×1080 target and it gives you a 1920×1080 canvas's worth of side padding. Feed in an image that's already 16:9 but only 640×360, and you get all zeros - the node is telling you "ratio's fine, now you go upscale." It's a helper, not a fixer.

Where the numbers go

The natural wiring is straight into ComfyUI's core Pad Image for Outpaint (ImagePadForOutpaint) node, which takes exactly these four INTs plus a feathering value. From there you mask the padded region, set denoising high (the extension is mostly new content), and generate. This is the classic masked route - and the honest caveat is that outpainting is the one place instruction-editing models took the job cleanly. If you're using Flux Klein or Kontext, the current community move is to pad the canvas with a solid color and tell the model to replace it, no mask needed. This node still earns its place if you're doing traditional outpainting where the original pixels must survive byte-for-byte, or if you're extending in steps and can't afford drift - that's the case where crop-and-stitch and masked outpainting still beat the edit models.

The trap

Besides the ratio-not-pixels thing, the main gotcha is that the node returns nothing visual. People drop it in, see four ints, and wonder where the image went. There is no image output in the schema - wire left/right/top/bottom into a padding node and the image comes out of that node. One more detail: it rounds the intermediate dimension to the nearest integer and integer-divides the remainder, so an odd leftover goes one pixel to the first side. Irrelevant at real resolutions.

Install

It's part of HB ComfyUI Nodes (HassanEclipse/comfyui-hb-party). ComfyUI Manager → Install via Git URL:

https://github.com/HassanEclipse/comfyui-hb-party

or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/HassanEclipse/comfyui-hb-party comfyui_HB_Party

Then restart. No dependencies, no model downloads, MIT license - the whole pack is pure Python plus one small JS file, so install is painless.

Bottom line

It's a five-line math helper wearing a big name, but it's a useful one. If you outpaint with mask-based workflows at consistent target ratios, it saves you from hardcoding padding or doing the arithmetic in your head. Just remember it's the front of the pipeline, not the whole thing.