☁️BizyAir InpaintModelConditioning
BizyAir InpaintModelConditioning — ComfyUI Node
- positive
- negative
- vae
- pixels
- mask
- positive
- negative
- latent
What it is
This node is more relevant right now than its plain name suggests. Inpainting used to mean loading a checkpoint fine-tuned specifically for masked editing. These days the community's actual default is different: take a modern editing model - Qwen-Image-Edit, Flux Kontext, whatever - and force real masked inpainting out of it, because those models are great editors but they aren't inpainters by default. They re-render the whole frame and let everything outside your mask drift a little. The fix people converged on is exactly this node: swap the plain empty-latent setup for InpaintModelConditioning, and the model gets told which pixels are ground truth and which it's allowed to touch.
If you only remember one thing from this article, it's this recipe, straight from the community: use InpaintModelConditioning instead of an empty latent, pair it with a scheduler that gives you a real denoise dial back, and stitch the result back onto the original with a crop-and-stitch node or ImageCompositeMasked so nothing outside the mask ever round-trips the VAE.
How it works
It takes your positive/negative conditioning, a VAE, your source image, and a mask, and produces conditioning plus a latent that already encodes "this region is fixed, this region is fair game." That's the structural difference from just masking a plain latent yourself - the model sees the unmasked pixels as context it's meant to preserve, not just guess-and-check against later.
Inputs and outputs
- positive / negative -
BIZYAIR_CONDITIONING, from your BizyAir text-encode nodes upstream. - vae -
BIZYAIR_VAE. Note the BizyAir-prefixed type: this only wires up to other BizyAir nodes, not a regular local ComfyUI VAE loader, because the whole subgraph is a cloud call under the hood. - pixels - the source image you're editing.
- mask - the region you're allowing the model to change.
Outputs are positive, negative (both BIZYAIR_CONDITIONING), and latent. Feed all three into your BizyAir sampler, same as you would with the stock ComfyUI version.
How to install it
ComfyUI Manager: search "BizyAir," install, restart. Manual:
cd ComfyUI/custom_nodes
git clone https://github.com/siliconflow/BizyAir.git
You need a BizyAir account and API key configured - every node here, including this one's downstream sampler, is a thin wrapper around SiliconFlow's cloud inference.
Common issues
Mixing this with regular ComfyUI nodes. The BIZYAIR_* types exist precisely so you can't accidentally do this - a stock VAELoader output won't plug into this node's vae input. If your graph won't connect, that's usually why: you need BizyAir loaders feeding BizyAir conditioning feeding a BizyAir sampler, end to end.
Detail still shifts outside the mask. InpaintModelConditioning fixes the conditioning, but it doesn't guarantee bit-identical unmasked pixels on its own - that guarantee comes from compositing the result back over the original afterward (an ImageCompositeMasked node, or a crop-and-stitch workflow) rather than letting the whole decoded frame stand as your final output.
Not sure whether you even need a mask node like this. If you can describe the whole edit in a sentence and don't care about pixel-perfect preservation outside the change, skip masking entirely and just prompt the edit - that's genuinely faster for most jobs now. Reach for this node specifically when the untouched part of the image has to survive exactly as it was, or when you need a partial-strength change (a denoise dial) rather than an instruction's all-or-nothing.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| positive | BIZYAIR_CONDITIONING | — | |
| negative | BIZYAIR_CONDITIONING | — | |
| vae | BIZYAIR_VAE | — | |
| pixels | IMAGE | — | |
| mask | MASK | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| positive | BIZYAIR_CONDITIONING | — |
| negative | BIZYAIR_CONDITIONING | — |
| latent | LATENT | — |