Stack_Ksampler_dual_paint

Regular inpainting gives you one denoise strength: the masked region gets that much change, the rest of the image is supposed to stay put. Stack_Ksampler_dual_paint gives you two separate denoise dials instead - one for the masked area, one for the rest of the frame - sampled together in one pass, plus an optional low-denoise refine step on top.

Inputs

• image and mask (both required) - your source image and inpaint mask.
• smoothness (INT, 0–500, default 0) - mask edge softness. 0 is a hard cutoff at the mask boundary; higher values soften the transition, the same idea as the mask-blur/feathering slider every inpainting workflow has had since A1111, just on a wider numeric scale here.
• mask_area_denoise (FLOAT, 0–1, default 0.1) and image_area_denoise (FLOAT, 0–1, default 0.9) - two independent denoise strengths.
• refine (BOOLEAN, default false) and refine_denoise (FLOAT, 0–1, default 0.1) - an optional low-denoise second pass after the main sample, for a detail touch-up.

Output: funtion - yes, that's genuinely how the socket is typed in the node's own schema (FUNTION, not a typo on our end), a quirk of the pack's naming rather than anything you did wrong.

Be honest with yourself about which region is which

The schema doesn't spell out whether "mask area" refers to the region the mask selects or the region it protects, and the default numbers (mask_area_denoise 0.1, image_area_denoise 0.9) don't obviously match the usual inpainting intuition of "heavy change inside the mask, none outside." Don't assume the conventional reading holds here - run it once on a throwaway image with an exaggerated mask and watch which region actually changes before you trust it on real work. This is exactly the kind of node where five minutes of testing saves you from quietly wasting an hour on a batch that changed the wrong half of the frame.

What "dual" is actually buying you

Because both regions get a denoise value rather than one being frozen entirely, this behaves less like classic masked inpainting's core guarantee (unmasked pixels survive byte-for-byte) and more like a soft, two-tier version of it, closer to how differential-diffusion-style techniques let denoise strength vary continuously across a frame instead of hard-cutting at a mask boundary. If your job specifically needs the rest of the image to come back pixel-identical, this node's design doesn't promise that the way a strict crop-and-composite workflow does - composite the result back over your original afterward if that guarantee matters to you.

Setting it up

Start from the defaults, generate once, and look carefully at both regions before adjusting either denoise value - you want to establish which knob is actually driving change in which area on your specific setup before you start tuning. refine with its own low refine_denoise (default 0.1) is meant as a light polish pass after the main sample, not a second full repaint - leave it off until your base result is already close.

Install

ComfyUI Manager: search "ComfyUI-Apt_Preset," install, restart. Manually: cd ComfyUI/custom_nodes && git clone https://github.com/cardenluo/ComfyUI-Apt_Preset.git, then restart. Its install.bat only runs on Windows - on Linux or a cloud box, check what it installs and pip-install those packages yourself, or let ComfyUI Manager's "install missing nodes" flow handle it.

Troubleshooting

If the whole image changes when you only wanted the masked region touched, that's the ambiguity above biting you - try swapping which denoise value you're treating as "the mask" and see if the result matches your expectation better.

This pack has real, reported import failures - a comfyui subreddit thread logs (IMPORT FAILED): ...ComfyUI-Apt_Preset. ComfyUI Manager's "install missing custom nodes" fixed it there, as did manually re-cloning the repo and restarting.