TripoSG RMBG Loader ⚡

TripoSG's preprocessing wants a subject on a clean background. If your image has an alpha channel it'll use that; if it doesn't, it runs BriaRMBG-1.4 to invent one. This node loads that remover. It's the smallest loader in the pack - one dropdown, one output - and it's the one everyone forgets to wire up before the pipeline tells them to.

What it loads

Bria's RMBG-1.4, the ~176 MB background-removal model that has become the default matte model in the ComfyUI ecosystem: a segmentation network with a config plus weights, folder-shaped rather than single-file. The node scans for directories that look like an RMBG install (config.json + model.safetensors), loads the network, and wraps it in a ComfyUI model patcher held in memory.

One input, model - the folder name under ComfyUI/models/triposg/, e.g. RMBG-1.4 or TripoSG/rmbg-1.4. One output, rmbg (CCTECH_TRIPOSG_RMBG), which connects to exactly one place: TripoSG Prepare Image's optional rmbg socket.

Note there's no precision widget here, unlike the UniRig loaders. That's deliberate - the README says RMBG runs in float32, and there's nothing to tune. A 176 MB model doesn't need to be half precision.

Why it's Bria's and not BiRefNet

The pack has two background removers, and this is the one TripoSG's preprocessing was built around. The TRELLIS.2 side uses BiRefNet. They are not interchangeable in practice: BiRefNet's output goes into core's Remove Background as a BACKGROUND_REMOVAL object producing a mask, while this one is consumed internally by Prepare Image as a matting stage with its own post-processing - Otsu threshold on the predicted mask, then small-blob cleanup. The downstream crop behaviour differs too, so don't swap them and assume parity.

Practical upshot: if you run both 3D pipelines, you'll have both models on disk in different folders. That's normal, not redundancy you should go clean up.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/ChrisColeTech/ComfyUI-GGUF-Loader
pip install -r ComfyUI/custom_nodes/ComfyUI-GGUF-Loader/requirements.txt

Manager install is fine as well. The requirements.txt route matters here because the TripoSG family wants scikit-image; the RMBG node itself is happy with just gguf, but its consumer isn't.

Then the weights. The split/RMBG-1.4/ folder comes down with the same Hugging Face download as the model itself:

huggingface-cli download ChrisColeTech/TripoSG \
  --include "split/TripoSG/*" "split/RMBG-1.4/*" --local-dir hf_triposg

Move hf_triposg/split/RMBG-1.4 into ComfyUI/models/triposg/RMBG-1.4. The scan is two levels deep, so the loader also finds an rmbg-1.4 folder nested inside the TripoSG folder - convenient if you've kept the upstream layout intact.

The failure mode that catches everyone

You connect the image, turn remove_background on (it's on by default), forget this node, and get:

TripoSG Prepare Image: connect a TripoSG RMBG Loader, or an alpha mask, or turn remove_background off.

That's not a broken install. It's the node correctly refusing to guess. Three ways out, and they're genuinely different choices:

• Wire this loader in. Best for photos and renders with no alpha.
• Pass LoadImage's mask (or any alpha) through instead. Best when the image already has a proper cutout - saves 176 MB of loading and gives you exact control over the matte.
• Turn remove_background off. The whole frame becomes the subject, centred and padded at padding_ratio. Right for images that are already just the object on a blank background, wrong for anything else.

Worth being clear about the licence, since Bria's weights have their own terms rather than the pack's Apache-2.0 - the pack's credits call this out explicitly. Personal projects, no issue. Anything commercial, read Bria's terms before you ship.

And the honest limit: RMBG is good on clear subjects and struggles the same way every matte model does - transparency, wisps, white-on-white. Since TripoSG reconstructs whatever it's handed, a leaky matte becomes a model of the leak.