MatteAnything_GenerateVITMatte
Soft alpha where other cutouts go hard
- image
- trimap
- vit_matte_model
- IMAGE
Every node so far has been building toward this one. MatteAnything_GenerateVITMatte is where the mask stops being a guess and becomes a real alpha matte - fractional, per-pixel transparency instead of a hard in/out call. This is the node you keep the result from, and the reason the pack's name has the word "Matte" in it and not just "Remove Background."
Why the extra step matters
Your SAM mask said "foreground here, background there." But a strand of hair is neither - it's 40% there, and glass is 80% there, and a hard mask can't express any of that. ViTMatte, the matting network this node runs, takes the image plus the trimap and predicts a continuous alpha value for every pixel in the unknown zone. That's the difference between a cutout that survives compositing onto a bright background and one that falls apart the second it leaves the preview.
The community shorthand for this is the "segmentation vs. matting" split - a mask is structurally the wrong output for anything semi-transparent, and this node is the pack's answer to that problem. The modern one-model way to get the same thing is a -matting variant of something like BiRefNet, but those don't let you steer the unknown band the way this trimap-driven pipeline does.
How it works
The node takes your image, the TRIMAP from MatteAnything_ToTrimap, and the VIT_MATTE_MODEL from MatteAnything_LoadVITMatteModel. It runs ViTMatte, grabs the predicted alpha from the model output, then - this is the part people don't expect - bakes it straight into the image's alpha channel and hands back an RGBA image. You don't get a separate mask to combine; you get a transparent PNG waiting to happen, subject already cut out with soft edges intact.
Inputs and outputs
- image - the original image, same one the whole pipeline has been using.
- trimap - from
MatteAnything_ToTrimap. This is the node where skipping ToTrimap catches up with you; a binary mask in here gives you a hard-edged result and defeats the purpose. - vit_matte_model - from
MatteAnything_LoadVITMatteModel. - Output: one
IMAGE, RGBA with the matte in the alpha channel. Feed it to aSaveImage, or straight into compositing.
Installing this pack
ComfyUI Manager, search Comfy_KepMatteAnything, install. Or:
cd ComfyUI/custom_nodes
git clone https://github.com/M1kep/Comfy_KepMatteAnything
then restart ComfyUI. This is the node that demands the full heavy stack - it literally builds the ViTMatte architecture through detectron2's config/instantiate machinery, so detectron2 isn't optional here (and it's the dependency that'll hurt most on Windows). You also need the ViTMatte weights:
mkdir -p ComfyUI/models/matte
# ViTMatte_B_DIS.pth into ComfyUI/models/matte/
Gotchas
- Launch ComfyUI from the ComfyUI directory. The pack finds ViTMatte's config via a relative path (
./custom_nodes/...), so starting ComfyUI from anywhere else makesLoadVITMatteModelfail before this node can even run. - Check your alpha in a viewer that honors it. ComfyUI's default preview often flattens alpha, so a result that looks "cut out wrong" may be a preview artifact. Save the PNG and look at it in something real before you go re-tuning the trimap.
- The first run feels slow. 2023-era ViT-B matting on a full-res image isn't instant. It's a single forward pass, so it's one-time pain per image - not a per-node tax you're doing wrong.
Honest take: this is the best-feeling node in the pack, because it's the only one whose output you'd actually hang on a wall. The pipeline around it is heavy and old, and modern one-model matting is genuinely easier to stand up - but when you've got the trimap dialed in, the alpha this thing produces is hard to argue with.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| image | IMAGE | — | |
| trimap | TRIMAP | — | |
| vit_matte_model | VIT_MATTE_MODEL | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| IMAGE | IMAGE | — |