BMAB KSampler Hires. Fix With Upscaler

Hires fix is one of those techniques everyone eventually adopts and nobody explains well the first time: generate at your model's native resolution, then run a second, lower-denoise pass at a higher resolution so you get more pixels without the double-heads-and-extra-limbs mess you get from just generating oversized in one shot. Normally that's two or three separate nodes wired together - an upscale, a KSampler, maybe a latent resize in between. BMAB's version collapses all of that into a single node, which is honestly the whole appeal.

How it works

This node takes a BMAB bind - the model/clip/vae/conditioning bundle you build upstream with BMAB Context and BMAB Model To Bind (and optionally BMAB Conditioning To Bind) - resizes the image inside it using classic interpolation, and then runs a fresh sampling pass over the result at low denoise. That's exactly the two-stage hires recipe from the KB: generate normally, upscale, then denoise lightly (0.3–0.5 is the sweet spot) so the second pass adds coherent detail instead of regenerating the composition from scratch. Push denoise too high here and you're not doing hires fix anymore, you're doing a fresh generation that happens to start from your first image.

Inputs and outputs

It's a dense node because it's doing the job of several. The pieces worth understanding:

• bind (required) - the BMAB context this node operates on.
• steps / cfg_scale / sampler_name / scheduler - the second-pass sampler settings. Note the sampler_name and scheduler dropdowns both include a "Use same sampler" / "Use same scheduler" option as their first choice, which just inherits whatever the first pass used - handy if you don't want to think about it twice.
• denoise (default 0.4) - the setting that decides how much the second pass is allowed to change. Stay in the 0.3–0.5 range unless you have a reason not to.
• model_name - an upscale-method enum (Lanczos in the sample data) for the resize step itself.
• scale / width / height - same pattern as BMAB Upscaler: a multiplier plus explicit target dimensions.
• Optional image - pass a specific image in rather than relying on whatever's riding in the bind.
• Optional lora - wire in a BMAB lora (from BMAB's own lora-loading node) if you want a different LoRA active just for this hires pass than the one used for the base generation.

Outputs are a BMAB bind (chain into the next BMAB node) and the resulting image.

Installing it

Through ComfyUI Manager: search comfyui_bmab, install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/portu-sim/comfyui_bmab.git
cd comfyui_bmab
pip install -r requirements.txt

This particular node doesn't need the two optional BMAB dependencies (comfyui_controlnet_aux, ComfyUI_IPAdapter_plus) - those only matter if you're also using BMAB's ControlNet or IPAdapter nodes elsewhere in your graph.

Common issues

The failure modes here are the same ones that trip people up on any hires-fix setup, BMAB or otherwise:

• Denoise too high, and the second pass drifts off-composition. If your upscaled result looks like a different image with the same vibe, that's the tell. Drop denoise back toward 0.3.
• Karras-style scheduler assumptions on the wrong base model. If you're running this on a flow-matching model (Z-Image, Flux, and similar) rather than an SD1.5/SDXL checkpoint, the "safe default" sampler/scheduler combo is different - aggressive schedulers like Karras actively hurt on those architectures instead of helping. Check what your base model actually wants before copying settings from an SDXL workflow.
• Forgetting this node needs a bind, not a bare image. If you're building your first BMAB graph, remember this node expects the output of BMAB Context (chained through a model/clip/vae bind) as its bind input - it's not a drop-in replacement for a stock KSampler on its own.