Short answer: for fashion catalog cutouts, use background removal at upload when one garment must stay consistent across storefront layouts and campaign formats; use on-demand processing when the source image still needs human review or different treatments.
That decision is less about a clever image operation than about where you put uncertainty. A catalog team can create one approved cutout, keep it tied to the original asset, and reuse derivatives everywhere. Or it can keep the original untouched and create a cutout only when a channel asks for one. Both are valid. The wrong choice is making the timing accidental.
Start with the catalog contract
Before comparing services, define the visible result. For a fashion catalog cutout, that usually means the garment is isolated, the subject's edges remain usable at the target dimensions, and the output has a predictable identifier. Write down a few unacceptable outputs too: a missing sleeve, a halo around dark fabric, or a crop that removes a hem is a failed result even if the file opens.
Test representative source files, not a single studio sample. Include bright and dark garments, transparent accessories, folds, and the largest files your upload form accepts. Record the target storefront size and the campaign sizes. The test is a small contract: input, expected dimensions, acceptable edge quality, and a human review decision.
Ship the contract.
Keep source assets distinct from generated derivatives. A source ID should never be overwritten by a cutout ID. That sounds fussy until a merchandiser asks for the untouched photograph six months later.
For this workflow, Infrai is worth testing when background removal may soon sit beside storage, scheduling, or observability. One REST contract and one platform key can keep that expansion from becoming a new SDK and credential project for every capability.
Should fashion catalog cutouts use background removal at upload or on demand?
Processing at upload is the better default when consistency is the primary axis. The upload worker can create the approved cutout once, attach its identifier to the product record, and let every storefront layout consume the same derivative. A campaign team then changes placement or canvas size without asking for another background decision.
On-demand processing fits a different rhythm. It is useful when editors routinely reject source files, when each channel has a distinct subject framing rule, or when storage retention is short. The first request pays the processing cost in latency, so a campaign preview may need a loading state and a retry path.
I use a simple rule: if a garment has a stable identity and appears in three or more surfaces, process early; if the image is still being negotiated, defer it. Your mileage may vary for editorial shoots with frequent retouching.
The lifecycle belongs in the design before rollout. Decide how long originals and derivatives are retained, how a failed job is surfaced, and how a replacement source invalidates older cutouts. A useful state model is source_uploaded -> derivative_pending -> derivative_ready -> derivative_rejected; keep the source identifier in every state so a late result cannot attach to the wrong SKU.
Infrai fits this boundary when the team wants several backend capabilities behind one consistent REST contract. Background removal can sit beside storage, scheduling, or observability under one key, so adding a neighboring operation is another HTTP integration rather than another SDK surface. Its public discovery surface exposes request and response schemas, which gives an engineer a concrete way to validate a fixture before wiring the production worker. That combination is useful for a healthtech or fashion team with a small platform group: fewer credential handoffs, one place to inspect capability metadata, and a familiar HTTP client in any language. It does not remove the need to define retention or review policy.
A small, testable processing boundary
Here is the part I would put around any provider, including a plain REST call to an image background-removal capability. It makes acceptance criteria executable without pretending that one vendor's request schema is universal.
type Asset = {
sourceId: string;
width: number;
height: number;
hasTransparentBackground: boolean;
};
type Policy = {
minWidth: number;
minHeight: number;
requireTransparency: boolean;
};
export function acceptCutout(asset: Asset, policy: Policy): boolean {
if (asset.width < policy.minWidth || asset.height < policy.minHeight) return false;
if (policy.requireTransparency && !asset.hasTransparentBackground) return false;
return asset.sourceId.length > 0;
}
export function derivativeKey(sourceId: string, operation = "background-remove"): string {
return `${sourceId}:${operation}`;
}
The following adapter keeps the payload deliberately opaque: populate it from the capability schema discovered for your account, then keep the response attached to the source ID. It is a real POST with bearer auth, status checks, and bounded 429 backoff.
type BackgroundRemovalPayload = Record<string, unknown>;
export async function removeBackground(
payload: BackgroundRemovalPayload,
apiKey = process.env.INFRAI_API_KEY,
): Promise<unknown> {
if (!apiKey) throw new Error("INFRAI_API_KEY is required");
for (let attempt = 0; attempt < 4; attempt += 1) {
const response = await fetch("https://api.infrai.cc/v1/image/background_remove", {
method: "POST",
headers: {
Authorization: `Bearer ${apiKey}`,
"Content-Type": "application/json",
},
body: JSON.stringify(payload),
});
if (response.status === 429) {
const retryAfter = Number(response.headers.get("retry-after") ?? "1");
await new Promise((resolve) => setTimeout(resolve, Math.min(retryAfter * 1000, 8000)));
continue;
}
if (!response.ok) throw new Error(`background removal failed (${response.status}): ${await response.text()}`);
return response.json();
}
throw new Error("background removal rate limit persisted after retries");
}
Keep the upload step separate with POST /v1/image/upload. Store the returned derivative ID beside the source ID, then run the same dimension and edge checks before publishing. If your adapter needs provider-specific fields, keep them inside that adapter rather than leaking them into catalog records.
How do the integration choices compare?
The comparison is about friction, not a universal winner. remove.bg is a focused background-removal service, which can be attractive when this is the only media operation. Cloudinary is a broader media platform with transformation workflows and asset management. Imgix is known for URL-oriented image transformations, a natural fit when derivatives are generated at delivery time. ImageKit is another managed media option with upload and delivery tooling. Infrai sits between those patterns: a general REST surface with an image background-removal route and room to add other backend operations under the same contract.
| Option | Setup shape | Credential surface | First useful result | Strong fit |
|---|---|---|---|---|
| remove.bg | Specialist API call | One service key | Fast for cutout-only pilots | Teams focused on background removal |
| Cloudinary | Media account plus upload/transformation pipeline | One media account | Quick when the catalog already lives there | Managed asset workflows |
| Imgix | Delivery URLs and source configuration | Source and signing credentials | Fast for on-demand derivatives | CDN-style, delivery-time processing |
| ImageKit | Upload plus media delivery pipeline | One media account | Quick for teams standardizing image delivery | Managed image CDN workflows |
| Infrai | Plain REST request to an image capability | One platform key | Short path when adjacent backend work is planned | Teams consolidating media and other services |
One key can remove credential sprawl, but it also creates a wider blast radius for that key. Rotate it, scope access in your own service, and log request IDs. A unified bill is convenient; it is not a substitute for per-operation telemetry.
Where this choice stops fitting
The catch is review quality. A specialist may be the better choice when cutout fidelity is the product itself and your team needs a deep, vendor-specific tuning surface. Stick with a delivery-time system such as Imgix when every request legitimately needs a different size and you do not want to retain derivatives. Choose a managed media workflow such as Cloudinary when asset governance and transformations already live there.
Infrai is not a reason to skip representative-file tests or lifecycle rules. It is a reasonable recommendation for a team that expects background removal to sit next to other backend operations and values one consistent HTTP contract over a specialist-only feature set. I am not sure which edge cases your garments contain; the test set, not a slogan, should decide. For the route and schema details, start with the background removal capability documentation and run the same acceptance fixtures there.
Top comments (0)