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.

5 min readSume
All posts

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.

RMBG request surface, read 2026-10-02
TopicBria remove_backgroundSume RMBG 1.0
InputBase64 or public URLPublic HTTPS URL
FormatsJPEG, JPG, PNG, WEBP (RGB, RGBA, CMYK)Not listed beyond a fetchable image URL
Keep input alphapreserve_alpha, default trueGray flatten when mostly transparent
ModerationOptional input and output flagsNo switch in the schema
OutputPNG with alphaMirrored PNG with alpha
Waitingsync flag or async status URLmode 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

All Media tools posts

Written by Sume