🔄 RGBA to RGB

A one-job node: take an image that's carrying an alpha (transparency) channel and hand back a plain 3-channel RGB image without it. You reach for this when something downstream errors or behaves oddly on a 4-channel image and doesn't actually need the transparency information anyway.

Why RGBA trips things up

Plenty of ComfyUI operations - VAE encoding especially - expect a straightforward 3-channel image and either error or silently misbehave when they get a 4th alpha channel instead. RGBA images show up more than you'd expect: PNGs with transparency, layer exports from an image editor, outputs from any node in this pack (or elsewhere) that produces a cutout. This node is the quick fix - strip the channel, move on.

Note what it doesn't do: it just removes the channel, it doesn't make a decision about what color should show through where the image used to be transparent. If you actually care about that - filling transparent regions with a specific solid color rather than however the raw channel-drop happens to render - the pack ships a separate Fill Background node built for exactly that, letting you choose the fill color deliberately. Reach for RGBA to RGB when you just need a valid RGB image and don't care what was in the alpha; reach for Fill Background when the fill color matters to the result.

The inputs and outputs that matter

• image - the RGBA image to convert.

One output: image, now 3-channel RGB.

Installing it

ComfyUI Manager: search SDVN_Comfy_node, install, restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/StableDiffusionVN/SDVN_Comfy_node

Then pip install -r custom_nodes/SDVN_Comfy_node/requirements.txt from your ComfyUI root, and restart. No models, no downloads - pure image-format plumbing.

Where people get burned

Running it on an image that's already RGB does nothing useful. If the error you're chasing wasn't actually an alpha-channel issue, this node won't fix it - check what shape your image actually is (a Show Image or Any Show node from this pack will tell you) before assuming this is the missing step.

If the fill color matters, this is the wrong node. Since it just drops the channel rather than compositing onto a chosen background, the visual result where transparency used to be depends on implementation detail you shouldn't rely on. Use Fill Background instead whenever you need a specific, predictable color underneath.

It's a symptom fix, not a pipeline fix. If images keep arriving with an unwanted alpha channel over and over in the same workflow, it's usually worth tracing back to whatever node is producing RGBA in the first place rather than dropping this conversion node in repeatedly downstream of it.