Nodes/ComfyUI Prompt Control/PC: Attach Mask (multi)
ComfyUI Node

PC: Attach Mask (multi)

Attach Mask (multi) — four regional masks in one node instead of a chain

By asagi4·Created 3 years ago·Updated about a month ago· 422
PC: Attach Mask (multi)
  • clip
  • mask1
  • mask2
  • mask3
  • mask4
  • CLIP

Exactly what the display name says: "Multi-input version of PCAddMaskToCLIP, for convenience." If your workflow needs several masked regions and you'd otherwise be chaining PCAddMaskToCLIP node after node - each one adding a mask without replacing the previous ones - this node does the same thing in a single step, with up to four masks attached at once.

What it does

Same mechanism as the single-mask version: it attaches masks to your CLIP object so they become addressable from inside a prompt via IMASK(), without touching the CLIP model's actual behavior otherwise. The difference is purely ergonomic - four mask inputs on one node instead of four separate PCAddMaskToCLIP nodes daisy-chained together. For a regional-prompting setup with several distinct areas (a multi-character scene, say, where each character gets their own region), this keeps the graph a lot tidier than the chained alternative.

If you need more than four masks in one setup, you're back to chaining - feed this node's CLIP output into a plain PCAddMaskToCLIP (or another Many node) to keep adding.

Inputs and outputs

Required: clip. Optional: mask1, mask2, mask3, mask4 - any subset can be left unconnected if you need fewer than four. Output: CLIP, carrying whichever masks you connected.

Installing it

ComfyUI Manager: search "ComfyUI Prompt Control", install, restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/asagi4/comfyui-prompt-control

No model downloads for this node - same as its single-mask sibling, you supply the masks from whatever mask-generation tooling you're already using.

Where people get tripped up

The same caveats as PCAddMaskToCLIP apply here, since it's the same underlying mechanism: this needs to sit before the PCTextEncode/PCLazyTextEncode node that references the masks with IMASK(), and the specific CLIP output from this node - not some other, unmasked CLIP - has to be what flows into that encoder. And the same architecture limitation from the README's known issues carries over too: this style of masking is built on the same idea as the pack's cutoff implementation, and it doesn't work with models that use non-CLIP text encoders like Flux. If you're wiring up a four-region regional-prompting setup and nothing's masking correctly, check you're on a CLIP-conditioned model before assuming the graph is wrong.

Order of mask1 through mask4 matters for nothing but your own bookkeeping - IMASK() addresses masks by index or name depending on how you referenced them in the prompt, so keep track of which input corresponds to which region as your graph grows.

Categorypromptcontrol/tools

Inputs (5)

NameTypeDefaultDescription
clipCLIP
mask1optMASK
mask2optMASK
mask3optMASK
mask4optMASK

Outputs (1)

NameTypeDescription
CLIPCLIP