ComfyUI Node

Hildegard Plan

The tile-grid brain of Hildegard — plan the upscale before you sample

By 42lux·Created 3 months ago·Updated 3 months ago· 57
Hildegard Plan
  • image
  • IMAGE
  • dac_data
tile_width1536
tile_height1536
min_overlap1/32 Tile
min_scale_factor3.00
tile_orderspiral
scaling_methodlanczos

Hildegard Plan is the node at the front of every Hildegard-Refiner workflow, and it does the boring half of the job on purpose: no model, no sampling, no AI at all. Feed it an image and it works out the upscaled dimensions and the tile grid your sampler is about to chew through one tile at a time, then resizes the image to fit with a plain interpolation (lanczos by default). Everything else in the pack - References Split, your sampler, Combine - trusts the numbers this node produces, so the whole pass lives or dies on the few dials you set here.

It exists because tiled upscaling needs a planning step. Ultimate SD Upscale and Tiled Diffusion bury theirs inside an extension; here the plan has to be shared, because both References Split and Combine need the exact same grid geometry, and Plan hands it to them as a single HILDEGARD_DATA payload. It's the "divide" half of divide-and-conquer, and it's genuinely the part Steudio's ComfyUI_Steudio contributed (the pack credits it, GPL-3.0) - the actual Hildegard contribution is the reference-latent scheme that comes next.

How it works

The solver picks the smallest tile grid that satisfies your three constraints - tile size, minimum overlap, and minimum scale factor - with all dimensions snapped to multiples of 16. That 16 is the latent-alignment of the Klein VAE, so every tile encodes cleanly with no partial latent cells. It then upscales the whole image in one shot with comfy.utils.common_upscale using the scaling_method you chose. Don't expect any magic here: the methods are nearest-exact, bilinear, area, bicubic, and lanczos. No ESRGAN model, nothing invented at this stage - that's correct. The detail comes later when FLUX.2 Klein samples each tile, with the three reference latents keeping every tile anchored.

The inputs that matter

  • tile_width / tile_height (default 1536 each, 16–8192) - the size of each tile the sampler will run on. This is your VRAM dial more than anything else; the bundled example workflow notes tiles from 1024 up to about 3048.
  • min_overlap (default 1/32 Tile) - how much of each tile repeats into its neighbors so the model sees context across seams. More overlap = smoother transitions, more redundant sampling.
  • min_scale_factor (default 3.0, 1–8) - the minimum scale you're after. It's a floor, not an exact target: the actual upscale ratio falls out of the tile size and grid geometry.
  • tile_order (default spiral) - the order tiles are indexed and processed; linear is plain row-major. Both Plan and Combine use the same ordering, which is what keeps tile i landing exactly back where it came from.
  • scaling_method (default lanczos) - the resize algorithm for the upscaled image.

Outputs

Two: the upscaled IMAGE, and dac_data (a HILDEGARD_DATA blob carrying the grid, overlaps, and ordering). Wire both into References Split, and feed dac_data to Combine later so it can stitch the tiles back in the same coordinates.

Install

Either ComfyUI Manager (search "ComfyUI-42lux-Hildegard-Refiner") or the manual route:

cd ComfyUI/custom_nodes
git clone https://github.com/42lux/ComfyUI-42lux-Hildegard-Refiner

Then restart ComfyUI. No pip dependencies - it's pure torch/PIL/numpy, but it uses the modern extension API, so it wants a current ComfyUI. And remember the pack's one hard requirement: the Hildegard LoRA from huggingface.co/42lux/hildegard, loaded as a normal LoRA before sampling. Without it, Klein has no idea what your reference latents mean.

Gotchas

The one everyone trips on: min_scale_factor won't give you an exact output size - it's a minimum, and the real ratio depends on your tile size. This was the most-asked question on the launch thread, and the author has said an explicit target-size option is on the way. Second, a pass that re-samples the image to your chosen scale happens here, so if the result looks soft before sampling, check your scaling_method before you blame the LoRA. And the classic: several smaller passes (~2x each) beat one giant jump - the README is blunt about that, and it matches how the community ended up running it.

Categoryupscale/hildegard-refiner

Inputs (7)

NameTypeDefaultDescription
imageIMAGE
tile_widthINT153616–8192
tile_heightINT153616–8192
min_overlapCOMBO1/32 Tile7 options: None, 1/64 Tile, 1/32 Tile, 1/16 Tile, 1/8 Tile, 1/4 Tile, +1
min_scale_factorFLOAT3.001–8
tile_orderCOMBOspiral2 options: linear, spiral
scaling_methodCOMBOlanczos5 options: nearest-exact, bilinear, area, bicubic, lanczos

Outputs (2)

NameTypeDescription
IMAGEIMAGE
dac_dataHILDEGARD_DATA