Change Channel Count

Most of the time you won't need this node at all - the pack's own README says so directly: every node in Masquerade Nodes does automatic conversion to whatever channel count it needs internally. Change Channel Count exists for the cases where you're crossing a boundary the pack can't see across: handing data to an external node from a different pack that assumes a fixed channel count, most commonly an inpainting node that specifically requires plain RGB.

There are three targets. mask collapses whatever you feed in to a single channel - if there's variable alpha, it uses that; otherwise it derives from overall image intensity. RGB forces exactly three channels, discarding any alpha that was there. RGBA forces four channels - if the source already had three, it adds a fully-opaque alpha; if the source only had one channel (a mask), all four output channels get set to that same value, so converting a mask to RGBA and back to a mask via intensity or alpha both land on the same result. That symmetry is deliberate and worth knowing if you're debugging a round-trip through this node.

The inputs that matter

• image - the image (or mask) to convert.
• kind - mask, RGB, or RGBA.

Output is the converted image, same content, different channel layout.

Installing it

Change Channel Count ships with Masquerade Nodes. Install through ComfyUI Manager (search "Masquerade Nodes") or manually: cd ComfyUI/custom_nodes && git clone https://github.com/BadCafeCode/masquerade-nodes-comfyui, then restart ComfyUI. Pure format conversion - no models, no extra dependencies.

Common issues

This node is worth understanding closely if you're chasing a stubborn seam or an off-center paste around Paste By Mask - some users have specifically traced tone shifts and misaligned pastes back to which kind was feeding into Paste By Mask upstream, with mask and RGBA behaving differently from RGB in ways that aren't obvious just from the node names. If you're getting a faint square outline or a color/tone mismatch around a pasted region, try switching this node's kind setting between the three options and compare results before assuming the problem is somewhere else in the graph - it's a cheap, fast thing to test given there are only three choices. Beyond that specific interaction, the node itself is simple enough that most "wrong" results trace back to picking a kind that doesn't match what the next node actually expects - check what the downstream node documents needing (RGB is the common one for external inpainting/detection nodes) rather than guessing.