imgix bg-remove skips transparent images; Sume RMBG flattens to gray

imgix's bg-remove=true leaves an image alone if it already has transparency or no detected background, and serves the origin image if removal fails. Sume's RMBG 1.0 treats a mostly transparent input differently: it flattens it onto mid-gray #808080 before the provider sees it, so the edges of an old cutout come out clean, and it is still one billed removal.

imgix's behaviour is from its bg-remove parameter page and Sume's from the Sume OpenAPI schema, both read on 2026-10-03.

How does imgix bg-remove behave?

bg-remove takes a boolean. The result has a transparent background and can be combined with other imgix transformations. Input formats are JPEG, PNG, WEBP, HEIF/HEIC and TIFF. imgix says images larger than 12 megabytes or 50 megapixels are optimized for background removal by default, and output images are limited to 10 MP and resized to fit.

Four caveats matter in production, all stated on the page: removal fails gracefully by serving the origin image, images that already contain transparency or have no detected background are skipped, completed removals are cached, and a first request can return a temporary response with status 200 or 423 while it processes. It may take up to a minute.

What does Sume RMBG do with transparent inputs?

Sume's route description says completed results expose mirrored PNG artifacts with alpha. When the input already has substantial fully-transparent pixels, which is typical when you re-cut an existing cutout, Sume flattens it onto #808080 before provider submission so edges stay clean. That is still one billed removal, and opaque inputs are unchanged.

So an already-transparent image is not skipped on Sume; it is processed again.

Why does that difference matter?

Skipping and re-cutting suit different pipelines. imgix skips because serving the right image fast matters on a page: if there is nothing to remove, do nothing. Sume re-cuts because you called a job on purpose, and you pay for a result.

Two practical points follow. With imgix, a failure is invisible in the response, because you get the original image back, so a page can show a photo with its background and nobody notices. With Sume, check the job's terminal status and fetch the result only when result_ready is true. And if you want to avoid paying to re-cut an image that is already clean, check that yourself before submitting.

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: recut-001" \
  -d '{
    "image_url": "https://example.com/inputs/cutout-v1.png",
    "mode": "async"
  }'

How do you avoid paying for a pointless re-cut on Sume?

Check the input before you submit. If you generated the cutout yourself, you already know it is done. If it came from a user, open it or probe its type. A JPEG cannot carry transparency, so every JPEG goes through removal, while a PNG may or may not already be cut.

Keep job ids next to the images. Because every Sume mode returns a job id in the first response, you can log which images were cut and skip them on a rerun, which is the safe pattern for batches and retries.

Which should you choose?

Choose imgix when the images are already served through imgix and you want background removal as one URL parameter with caching. Choose Sume when you want an explicit job, mirrored PNG artifacts with alpha, and a result you can attach to other Sume media jobs. The hosted MCP tool is rmbg_create, listed in MCP tools and gates.