Bria remove background preserve_alpha vs Sume RMBG on cutouts
Bria's remove_background has preserve_alpha and moderation flags. Sume RMBG 1.0 has neither; it flattens already-transparent inputs onto gray before cutting.

Bria's POST /remove_background takes a preserve_alpha flag (default true) to keep partial transparency from the input, while Sume RMBG 1.0 has no such flag. Instead, when the input already has substantial fully transparent pixels, Sume flattens it onto mid-gray #808080 before cutting, and returns a PNG with alpha.
Bria's facts come from its Remove Background documentation, read on 2026-10-02. Sume's come from the Sume OpenAPI description of POST /v1/rmbg-1.0/remove, and the MCP tool list, where the tool is rmbg_create.
What does Bria's remove_background accept?
The Bria page lists a required image (a base64 string or a public URL), JPEG, JPG, PNG or WEBP input in RGB, RGBA or CMYK, and a 415 for unsupported types. Optional fields are preserve_alpha, sync (default false, so asynchronous with a status URL), webhook_url, and two content-moderation switches for the input and the output. The output keeps varying levels of transparency, as a PNG with an alpha channel, and the page names the model as RMBG 2.0.
The page does not state a price, so this post does not compare prices.
What does Sume RMBG 1.0 accept?
The Sume request has an image_url (a public HTTPS URL, and the schema prefers a Sume media or attachment URL), an optional sync_mode passthrough, optional metadata, and the usual communication fields: mode (async by default), webhook_url and wait_timeout_seconds up to 30. Completed results expose mirrored PNG artifacts with alpha.
There is no base64 input, no moderation switch and no preserve_alpha. The route description is explicit about the one pre-processing step: for an input with substantial fully transparent pixels, typically a second cutout of an earlier cutout, Sume flattens onto #808080 before submitting, "so edges stay clean", and it is still one billed removal. Opaque inputs are unchanged.
Why does the transparent-input rule matter?
A cutout you already made has soft edges that a second pass can misread, which is the case the gray flatten is meant for. Bria's answer is a switch that tells the endpoint to keep the incoming alpha. Sume's answer is to remove the choice, and flatten onto a neutral gray every time the transparent ratio is high.
That is a product decision, and it means you cannot opt out. If your pipeline depends on the incoming alpha surviving untouched, test one image through both routes. The earlier post on re-cutting a PNG that already has transparency shows the behaviour on Sume.
How do I test the edge quality on my own images?
Pick ten images: three fresh product photos, three earlier cutouts with soft edges, two with hair or fur, and two with glass or a shadow. Run all ten through each route and place the results on the same dark and light backgrounds. The failures show at the fringe, so look at the edge pixels at 200% zoom, not at the thumbnail.
For the earlier cutouts, run the input once as it is. On Sume the gray flatten happens for you when the transparent share is high, and the docs do not say where, if anywhere, that is reported. On Bria, run once with preserve_alpha true and once false, and keep the better one. Write down which images changed, because that tells you whether the switch matters for your catalog at all.
Sume's result is a Sume-owned URL, so the mirrored PNG stays available for the next step, for example a cutout then upscale chain. Bria's output is returned as an image URL, and the page does not say how long it lives, so copy it if you need it later.
How do the routes line up?
Only documented behaviour is listed.
| Topic | Bria remove_background | Sume RMBG 1.0 |
|---|---|---|
| Input | Base64 or public URL | Public HTTPS URL |
| Formats | JPEG, JPG, PNG, WEBP (RGB, RGBA, CMYK) | Not listed beyond a fetchable image URL |
| Keep input alpha | preserve_alpha, default true | Gray flatten when mostly transparent |
| Moderation | Optional input and output flags | No switch in the schema |
| Output | PNG with alpha | Mirrored PNG with alpha |
| Waiting | sync flag or async status URL | mode async, sync up to 30 s, or webhook |
What do I do with the job on Sume?
Submit, then poll the job envelope instead of holding the connection. A sync wait that times out does not mean the job failed: the jobs page says to poll, not resubmit, and /result answers 409 job_not_completed until the result is ready. Use an Idempotency-Key so a retry does not queue a second removal.
curl -X POST https://api.sume.com/v1/rmbg-1.0/remove \
-H "Authorization: Bearer $SUME_API_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: rmbg-demo-001" \
-d '{
"image_url": "https://media.sume.com/artifacts/artf_demo/product.png",
"mode": "async"
}'Sources
Related posts
More in Media tools
- Burn Japanese, Chinese or Arabic captions: what Sume documents
Sume's caption docs list Latin and Hangul faces only. For other scripts, test one clip first, or ship a sidecar file where the platform takes one.
- Captions with sound cues for deaf viewers: W3C checklist on Sume
W3C says captions carry speech and non-speech sound. Sume's STT burn covers speech only, so here is how to author the full cue list and burn it.
- Caption a dubbed video: new job, not source_caption_id
source_caption_id reuses the first video's word timings, so a dub needs its own caption job on the dubbed file. How Sume handles it, and the cost.
- caption_no_speech on a silent clip: burn Halloween text with cues
A silent AI clip fails video captions with caption_no_speech. Pass cues with text, start and end instead: a worked giveaway announcement on Sume at $0.20.
Written by Sume