Which Managed Media API Platforms Handle Product-Image Background Removal and Object Erasing in One Pipeline?

Clean product images come out of two Bria models chained: bria-eraser removes unwanted objects first, then bria-image-remove-background cuts out the product. Both are active in GMI's model library and run on GMI Cloud Model-as-a-Service (MaaS). Each is called the same way: a POST to the request-queue endpoint with a Bearer API key, then a GET on the request_id for the result, and the output URL of the first step becomes the input of the second. The same endpoint also serves the upscaling, dimension-image, and video Bria models in the library, so extending the pipeline changes a model ID and a payload, not the endpoint or the key.

The pipeline at a glance

Every row uses the same submit endpoint, POST https://console.gmicloud.ai/api/v1/ie/requestqueue/apikey/requests, with a body of model and payload.

Erase on the original photo, cut out last

Erasing goes first and the cut-out goes last. The mask is drawn against the photo your catalog holds, and the eraser's inputs are an image and a mask. Running it first keeps it on that original photo. And the cut-out is the step with a transparent result: the model detects the primary foreground subject, removes everything behind it, and returns the subject on a transparent background, suitable for compositing onto a new background. With the cut-out last, the transparent output is the final file, and no later model takes a transparent PNG as input.

If your catalog needs a larger master image, put bria-image-increase-resolution between the two steps, for the same reason.

Inputs for background removal and the eraser

Background removal. bria-image-remove-background has one required parameter, image, accepted as a JPEG or PNG in a Base64 string or a URL. It is powered by Bria's RMBG 2.0. Bria's own model card for RMBG v2.0 says the model is designed to separate foreground from background across a range of categories and image types, and that its training data includes e-commerce along with stock, gaming, and advertising content.

Object erasing. bria-eraser erases objects from images. Its schema, returned by GET /api/v1/ie/requestqueue/apikey/models/{model-id} as described in the video API reference, lists two required parameters: image and mask.

The mask convention comes from Bria's own Eraser documentation. White (pixel value 255) marks what to erase and black (0) marks what to keep, and the mask must have the same aspect ratio as the input image. That documentation names two ways to produce masks: let people draw on the image with a brush, or generate regions with Bria's segmentation route. The mask is an input your pipeline creates. In a fully automated catalog the mask comes from one of three places: a rule such as a fixed region where a watermark or label sits (a black image of the photo's dimensions with that rectangle filled white), a detection or segmentation model of your choice upstream, with its boxes or regions rasterized into the mask at the photo's own pixel dimensions when positions vary, or a reviewer's brush tool for the exceptions. Photos that have nothing to erase skip the first step.

Two calls, one helper

The helper below submits a job, reads the submit response, and polls until the job has a result. A response that already holds the result returns immediately, and a job that is not finished gets polled with a growing interval, with the time budget checked before each wait. Each HTTP call also carries a connect and read timeout, so a stalled connection fails instead of hanging.

import time, requests

BASE = "https://console.gmicloud.ai/api/v1/ie/requestqueue/apikey"
HEADERS = {"Authorization": "Bearer <GMI_API_KEY>"}

def run(model, payload, budget=300, interval=2):
    start = time.monotonic()
    r = requests.post(f"{BASE}/requests", headers=HEADERS,
                      json={"model": model, "payload": payload},
                      timeout=(5, 30))
    r.raise_for_status()
    job = r.json()
    while not (job.get("status") == "success" and job.get("outcome")):
        if job.get("status") in ("failed", "cancelled"):
            raise RuntimeError(job)
        if "request_id" not in job:
            raise RuntimeError(job)
        if time.monotonic() - start + interval > budget:
            raise TimeoutError(job["request_id"])
        time.sleep(interval)
        interval = min(interval * 1.5, 15)
        g = requests.get(f"{BASE}/requests/{job['request_id']}",
                         headers=HEADERS, timeout=(5, 30))
        g.raise_for_status()
        job = g.json()
    return job["outcome"]

def result_url(outcome):
    # Bria image models on GMI that document their response return result files in outcome.media_urls
    return outcome["media_urls"][0]

erased = run("bria-eraser", {"image": photo_url, "mask": mask_url})
cutout = run("bria-image-remove-background",
             {"image": result_url(erased)})

The status values on the remove-background page are queued, processing, success, and failed, and on success its URLs are in outcome.media_urls. Copy each result file into your own storage when a step succeeds, and keep the step's output URL or file next to the SKU. If step two fails, you retry step two from the stored step-one result instead of submitting the erase again.

Getting photos and masks to the API

Image inputs can be a hosted URL or a Base64 string. A hosted URL must be publicly accessible, and some hosts block cross-site requests or rate-limit them. A data URI suits small files, and large payloads can slow requests.

If your photos and masks sit in private storage, GMI provides a two-step Upload API. Request an upload URL with POST /api/v1/ie/requestqueue/apikey/upload-url and a file_type of jpeg, jpg, or png for images, then PUT the bytes to the returned upload_url, which is valid for about 15 minutes. The response also carries a public_url, a stable, publicly accessible address you can pass wherever a hosted URL is accepted. The same route handles both the source photo and the mask, with no public bucket to run.

Running a catalog through it

Each request processes a single image, so a catalog is many jobs, and the pipeline is a worker pool around the helper:

• Bound the concurrency and make it a setting. Run the steps from background workers instead of the request path of a user-facing page, and feed the pool from your own job queue so waiting SKUs sit in the queue and not in blocked threads. Rate limits are enforced at the organization level, so a batch run and live traffic under the same organization share the same limits. Back off on 429 responses instead of retrying at full speed, and size the pool so product pages that call the API in real time are not starved.
• Keep a row per SKU and per step. Store the SKU, the step, the request_id, and the stored output. A restart then resumes at the first SKU without a finished step.
• Send the exceptions to a person. Photos where a reviewer flagged an object get a mask first.
• Set the output format once. The cut-out is a transparent image meant for compositing; decide in your compositing step what canvas, color, and file format the storefront needs.

Other Bria steps on the same endpoint

Three more image models in the library are called the same way:

• bria-genfill fills masked regions with prompt-guided content. Its schema requires image, mask, and prompt, and takes optional negative_prompt, guidance_scale, and num_inference_steps. Use it when the masked area should become something new rather than empty background.
• bria-image-increase-resolution upscales by 2x or 4x, with 2x as the default.
• bria-product-dimensions turns a product photo and real-world measurements into a dimension image on a clean canvas. It needs a style and at least one of height_value, width_bottom_value, or width_top_value. It is a separate output of the cleaned photo, so run it next to the cut-out and not in place of it.

The video versions

Short product clips use the same pattern with two video models. bria-video-remove-background takes an input video URL of up to 60 seconds, and its background_color defaults to Transparent. A transparent result needs an output format that supports alpha, such as webm_vp9. bria-video-eraser takes a video and a mask video. The video can be up to 5 seconds, with input above 750p downscaled, and the mask must be shorter than 5 seconds. Both are labeled async, return their file in outcome.video_url, and add cancelled to the status values, so the polling helper above needs only the new model IDs, the video payloads, and a longer deadline.

FAQ

What if a product photo shows several items and we only want one of them cut out?

Describe the item you want in the prompt of bria-extract-object, which takes an image plus that prompt on the same endpoint and key as the other Bria steps. When similar items share the frame, name the one you mean, such as "the sneaker on the left". Turn on autocrop to tighten the canvas around the object. Leave remove_background off for a faster cut that avoids over-trimming text, logos, and graphics, or turn it on for softer, matte-quality edges. Run it as a branch beside the erase-then-cut-out pipeline for multi-item frames.

Can the same API change a product photo's background scene or lighting?

Two more Bria models cover both jobs on that endpoint. bria-fibo-edit-1.5 takes one to four source images and a text instruction, such as a new background scene. An optional mask (white is edited, black is preserved) protects the product area when a single source image is sent, and a seed makes a result reproducible. bria-fibo-relight takes a light_direction (front, side, bottom, or top-down) and a light_type such as midday, overcast, soft bokeh, or harsh studio. Run either as its own branch beside the transparent cut-out.

Run the pair on one product photo

Pick one product photo with an object you want gone, draw its mask, and run the two calls above with a key from the GMI Cloud console. Check the cut-out on a white and a dark canvas, then scale the same worker pool to the rest of the catalog.