BMAB SD-WebUI API T2I Hires.Fix
Driving an A1111/Forge instance from inside ComfyUI
- hires_fix
This one's a different animal from the rest of the pack. Every other BMAB node runs on ComfyUI's own model, sampler, and VAE. This node doesn't - it's a client for the Automatic1111 (or Forge) WebUI's REST API, sending a text-to-image-plus-hires-fix request to a separately running SD WebUI instance and pulling the result back into your ComfyUI graph. Think of it less as a sampler and more as a bridge: it lets a BMAB pipeline reach out to an A1111-family install for the specific generation step, rather than doing everything natively in ComfyUI.
Worth knowing going in: AUTOMATIC1111's own WebUI has had no commits to its master branch since July 2024 - it's frozen, not actively developed, though plenty of people still run it, and Forge (an actively maintained fork) speaks the same API. Either way, this node needs something listening on that API to be useful at all; it's not a fallback that works standalone.
Why the dropdowns come up empty
Four of the required fields - upscaler, sampler, scheduler, checkpoint - are enum dropdowns, and out of the box every one of them has zero options. That's not a bug in this pack; it's because this node populates those lists by querying your running WebUI instance for what it actually has installed. No reachable WebUI, no options. If you're setting this up, the WebUI needs to be running and its API reachable before you'll see anything useful in these dropdowns.
The rest of the inputs
promptandnegative_prompt- standard text fields, sent straight through to the WebUI's own generation call.scale(0-4, default 2) - the hi-res upscale multiplier, same concept as A1111's own Hires. fix upscale-by setting.width/height(default 1024 each) - your base generation resolution before the hires pass.steps(default 20) - sampling steps for the WebUI's own generation.
The output is a single value of BMAB's own Hires.fix type - not an IMAGE - which tells you this node is meant to feed into something else downstream in BMAB's pipeline that knows how to consume that type, rather than being a terminal step you'd wire straight into a save node.
Installing it
The comfyui_bmab side installs the normal way - ComfyUI Manager, search comfyui_bmab, install, restart, or manually:
cd ComfyUI/custom_nodes
git clone https://github.com/portu-sim/comfyui_bmab.git
cd comfyui_bmab
pip install -r requirements.txt
That gets you the node. It does not get you an SD WebUI to talk to - that's a completely separate install (AUTOMATIC1111/stable-diffusion-webui or a Forge fork), run somewhere reachable from wherever ComfyUI is running, with its API enabled. If you're running ComfyUI on a hosted or serverless platform rather than your own machine, there's a good chance you have no local WebUI instance for this node to reach at all - it's built for a setup where both tools live side by side.
Where this bites
The single most common confusion is expecting this node to work like BMAB's other sampler nodes - plug it into a bind, get an image out. It doesn't take a bind at all, and its output type isn't even IMAGE. The second is spending time debugging "empty dropdown" as if it's a pack bug, when it almost always means the WebUI API just isn't reachable yet - confirm the WebUI is actually running and its API flag is enabled before assuming anything is broken on the BMAB side.
Inputs (10)
| Name | Type | Default | Description |
|---|---|---|---|
| prompt | STRING | — | |
| negative_prompt | STRING | — | |
| upscaler | COMBO | 0 options: | |
| sampler | COMBO | 0 options: | |
| scheduler | COMBO | 0 options: | |
| checkpoint | COMBO | 0 options: | |
| scale | FLOAT | 2.0000–4 | — |
| width | INT | 1024128–4000 | — |
| height | INT | 1024128–4000 | — |
| steps | INT | 200–1000 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| hires_fix | Hires.fix | — |