Nodes/ComfyUI-Image-Filters/Inpaint Condition Encode
ComfyUI Node

Inpaint Condition Encode

Do the expensive VAE encode once, not every prompt tweak

By spacepxl·Created 3 years ago·Updated 8 months ago· 293
Inpaint Condition Encode
  • vae
  • pixels
  • mask
  • inpaint_condition

If you've done any serious inpainting work, you know the loop: paint a mask, run the sampler, hate the result, tweak the prompt, run again. Standard inpaint conditioning setups re-run the VAE encode of your full image every single time through that loop, even though the image and mask haven't changed - only the prompt did. This node exists to break that dependency: it does the VAE encode once, packages the result, and hands you something you can reuse across as many prompt iterations as you want without paying the encode cost again.

Why this split matters

The README states the intent plainly: it "separates the VAE encode from the conditioning so you don't have to re-encode latents every time you change a prompt." A full-resolution VAE encode isn't free - on a big image it's a real chunk of your generation time, and if you're iterating on wording ten times to get a prompt right, you're paying that cost ten times for no reason. This node is the first half of a two-node pair: it produces a portable bundle (the pack's own custom INPAINT_CONDITION type), and its partner, Inpaint Condition Apply, is what actually turns that bundle plus your current prompt into conditioning and a latent for the sampler. Encode once here, apply as many times as you like there.

It's functionally in the same territory as ComfyUI core's own InpaintModelConditioning node - both exist to give inpainting-aware models (Flux Fill and similar) a clean way to condition on the masked region - but this pack's split into two separate nodes is specifically built around avoiding redundant encode work across iterations, which the stock node doesn't optimize for.

Inputs and outputs

  • vae (VAE) - the VAE to encode with. Has to match whatever model you're sampling with downstream.
  • pixels (IMAGE) - the image you're inpainting.
  • mask (MASK) - the region you want regenerated.

The single output is inpaint_condition, typed INPAINT_CONDITION - this is a pack-specific bundle, not a standard ComfyUI type, so the only thing downstream that understands it is Inpaint Condition Apply. Wire it there.

Installing it

Through ComfyUI Manager: search "ComfyUI-Image-Filters," install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/spacepxl/ComfyUI-Image-Filters

pip install -r requirements.txt (or install.bat on Windows), restart. No model downloads required for this node itself - you still need whatever inpainting-capable checkpoint you're conditioning for, but this pack adds none of its own weights.

The recurring install snag across this whole pack is OpenCV: it depends on opencv-contrib-python, and if another custom node pack already installed a different opencv build, you'll see import errors on startup. Run import_error_install.bat (shipped alongside the normal installer) to clean up every opencv variant and reinstall the correct single one.

Common issues

The most likely mistake is treating inpaint_condition like it's usable on its own - it isn't; it's an intermediate bundle that only means something once it reaches Inpaint Condition Apply, which is where your positive/negative prompt actually gets attached. If your mask and image don't match resolution, expect the encode to either error or silently misalign - same rule as any inpainting workflow: paint the mask against the exact image you're feeding in here. And because this node genuinely front-loads all the encode work, don't expect any speedup from it on a single one-shot generation - the payoff only shows up once you're iterating the prompt multiple times against the same masked image.

CategoryImage-Filters/conditioning

Inputs (3)

NameTypeDefaultDescription
vaeVAE
pixelsIMAGE
maskMASK

Outputs (1)

NameTypeDescription
inpaint_conditionINPAINT_CONDITION