GigaHires Refine Pass

The upscale step just makes the canvas bigger. This node is where the actual hires fix happens: a second, lower-denoise sampling pass over the already-upscaled latent that invents the detail the first pass couldn't fit. If you're generating above native resolution and seeing tiling, duplicated anatomy, or mush, this is the stage that fixes it - and the one that eats your time budget while doing so.

What it does

It runs a KSampler-equivalent on the latent you feed it, at the denoise you choose, then decodes the result. Crucially, it does not upscale anything - that's already been done upstream by GigaHires Latent Upscale or GigaHires Image Upscale. Get that wrong and the node will silently do very little, because refining a small latent at low denoise just… doesn't change much.

The one knob that matters

denoise (default 0.35). This is the heart of the whole technique:

• Too low (under ~0.2) and the second pass barely touches anything - you keep the blockiness from the latent upscale.
• Too high (above ~0.5) and the composition drifts, faces shift, the image stops being your image.

The community playbook and the author's own testing land in the same place: 0.30–0.40 for the latent branch, 0.25–0.35 if you went through a learned upscaler first. Start at the default and nudge.

The rest of the sampler inputs are standard - steps (default 12, and it's fine to run fewer than the first pass), cfg (default 7), sampler_name (dpmpp_2m) and scheduler (karras). Those two defaults are notably better-behaved than the coordinator node's, by the way.

vae_mode matters at big sizes. regular is fine until you're pushing high resolutions; tiled splits the decode into vae_tile_size (512) chunks with vae_overlap (64) so you don't OOM on a 4K decode.

The timing reality

The pack's own measurements are worth knowing before you're surprised: at a 2304×1536 target, the sample inside this node took ~28s and the decode ~1.4s; at 3072×2048 it was ~55s sampling vs ~2.75s decode. The second-pass sampler dominates the entire hires budget, and it scales with latent size and steps. So: the dials that cost you time are steps and the upscale factor you chose upstream - not denoise, not the VAE. And per the author's notes, throwing more steps at a blocky latent branch doesn't actually fix the blockiness; switch upscale branches instead.

Outputs

refined_latent and refined_image are your finished result - save the image or keep the latent going. debug_info is the JSON breakdown of steps, cfg, sampler, denoise, latent shape, and sample/decode timings; route it into GigaHires Debug Print if you want it readable.

Where people get burned

• Expecting it to upscale. It refines, it doesn't resize. Pair it with the upscale node, not instead of it.
• One pass on a face. The broader KB lesson applies here too: if faces matter, give them their own pass rather than trusting one refinement run.
• Old ComfyUI. This is a comfy_entrypoint-style native extension pack; stale builds won't even show the node.

Install

Manager → search "comfyui-hires", or:

cd ComfyUI/custom_nodes
git clone https://github.com/Enferlain/comfyui-hires

Restart ComfyUI. No requirements.txt, no pip installs - just a current ComfyUI.