Ecommerce product images: normalising a whole catalogue
Forty suppliers, forty different backgrounds, one grid that has to look deliberate. Enlarge, cut out, composite onto white, encode — four steps per SKU, three of them API calls. The order they run in matters more than which tools you pick, and one of the four is not something this API can do for you.
as supplied
after the pass
Four steps per SKU, in this order
The sequence is the part people get wrong, and it is easy to get wrong because the intuitive order sounds more efficient. Enlarge before you cut out, never after.
- 115 cr
upscale_imageIf the supplier photo is below the marketplace resolution floor.
Do this first, while the background is still there. Read the dimensions off the result — there is no scale factor to set, so the model decides how big it comes back.
- 28 cr
remove_backgroundAlways, for a main listing image.
Matting rather than a hard mask, so anti-aliased edges stay usable. Returns a transparent PNG.
- 3free
composite onto whiteFor any marketplace that demands a white background.
Yours to do — no endpoint here sets a background colour. One line locally, and the only way to hit RGB 255,255,255 exactly.
- 41 cr
compress_imageTo meet a file-size ceiling, or for your own grid.
Optional if you are already encoding locally during the composite step, since by then you have the bytes anyway.
Why not cut out first?
Because it seems cheaper — why pay to reconstruct pixels you are about to delete? — and because it quietly destroys the work. The upscaling model does not support transparency: hand it a cutout and the transparent area comes back white, so the alpha channel you just paid 8 credits to create is gone. The call still succeeds and still bills. Enlarge the photo while it still has a background, then cut out.
Getting to pure white — the step the API does not do
A cutout is transparent, not white, and encoding it to JPEG here puts the product on black. This is the single most expensive misunderstanding in a catalogue pipeline, because it produces images that look plausible in a file browser and get rejected on upload.
JPEG has no alpha channel, so something has to fill the transparent area. Neither our compression nor our conversion endpoint exposes a background colour, and the encoder’s default fill is black. Ask either of them for a JPEG of a cutout and the product arrives on a black rectangle. Ask for WebP instead and the transparency is preserved faithfully — which is right for your own site, and still not the pure white a marketplace main image wants.
So the compositing step belongs on your side. It is one line, it costs nothing, and it is the only way to land on RGB 255, 255, 255 exactly rather than approximately.
Why photographing white does not work
Shooting on a white sweep gives you something in the 240s with a colour cast from the lighting, not 255. That is why the cut-out-and-composite route exists at all: you set the background as a number instead of trying to light one.
import sharp from "sharp";
// remove_background gave us a transparent PNG.
const cutout = await fetch(result.imageUrl).then((r) => r.arrayBuffer());
// Encoding that straight to JPEG puts the product on BLACK.
// Flatten onto white first — this is the step the API does not do.
await sharp(Buffer.from(cutout))
.flatten({ background: "#ffffff" }) // RGB 255,255,255
.jpeg({ quality: 90 })
.toFile(`listings/${sku.id}.jpg`);Running it in batches
Every step here is independent per SKU, which makes the whole job a natural fit for multicall. A batch is priced by summing its items, deducted once up front, and dispatched in a single parallel execution — and any items that fail are refunded individually rather than failing the batch.
Impose your own batch size
There is no cap on how many requests a multicall may contain, and they are all dispatched at the same instant. That is a feature at twenty and a problem at a thousand. Keep batches in the tens and drive them from a queue that writes each returned URL back against its SKU.
// Batch in modest groups — multicall has no size cap, and every
// item in a request is dispatched at the same moment.
const batch = skus.slice(0, 20).map((sku) => ({
tool: "remove_background",
args: { image: sku.upscaledUrl }, // already enlarged
}));
const res = await fetch(
"https://api.imagemcpserver.com/v1/multicall",
{
method: "POST",
headers: {
Authorization: `Bearer ${process.env.IMAGEMCP_API_KEY}`,
"Content-Type": "application/json",
},
body: JSON.stringify({ requests: batch }),
}
);
const { results } = await res.json();
// One result per SKU, in the order sent. Failed items are
// refunded individually — check result.success per entry.Where generation actually earns its keep
Normalising catalogue photos is editing work, and a dedicated cutout service does the cutting more cheaply. Generation becomes interesting one step later, when you need the same product in six different settings — a summer campaign, a Christmas grid, a lifestyle shot for the category page — and a photo shoot for each is not happening.
A cutout plus edit_image gives you that, at 8 to 30 credits a call depending on the model. These belong in the gallery images rather than the main one, where marketplace rules are much more relaxed. The product stays the real photograph; only what surrounds it is generated.
"Place this chair in a sunlit Scandinavian living room, oak floor"
"Same product, autumn setting, warm low light, soft shadow"
"Studio shot on seamless grey, single soft key from the left"
Where to draw the line
Worth being deliberate about, because the failure mode is expensive in returns and in regulatory attention.
The rule of thumb: the customer should be able to hold the item next to the picture and agree it is the same object.
What it costs at catalogue scale
| Step | Tool | Credits |
|---|---|---|
| Enlarge to clear the resolution floor | upscale_image | 15 |
| Cut the product out | remove_background | 8 |
| Composite onto pure white | your own code | 0 |
| Encode for the listing | compress_image | 1 |
| One SKU, full treatment | 24 | |
Or 9 credits where the source already clears the resolution floor and no enlargement is needed. A thousand SKUs at the full treatment is 24,000 credits — a number to size against a plan before you queue the job.
Be clear-eyed about volume
If background removal is the only thing you need, at thousands of images, a dedicated per-image cutout service will beat this on unit price by a wide margin. That is what a single-purpose product is for, and several of them are very good. We would rather say so than have you discover it on the invoice.
The case for doing it here is heterogeneity. When one SKU needs enlarging, the next needs a seasonal backdrop, and a third just needs re-encoding, the work is a decision per item rather than a single repeated operation — and that is the shape an agent can drive end to end behind one key and one bill, instead of you assembling three vendors and the glue between them. See plans.
Catalogue pipeline questions
Why do my white-background product photos keep getting rejected?
Almost always because the background is not actually white. Marketplaces that ask for a white background mean RGB 255, 255, 255 exactly, and you will not get that out of a camera even shooting on a white sweep — studio lighting leaves it somewhere in the 240s with a colour cast. That is why the cut-out-and-composite route exists: isolate the product, then place it on a background you set numerically rather than one you photographed. Checked September 2026.
Does this pipeline produce a pure white background on its own?
No, and this is the one limitation to plan around. Background removal returns a cutout with a transparent alpha channel. If you then encode that to JPEG through either our compression or our conversion endpoint, the transparent area is flattened to solid black, not white — a listing image that will be rejected immediately. Neither endpoint exposes a background colour, so the compositing step has to happen on your side. It is one line in most image libraries, and the page shows where it goes.
How strict are marketplace image requirements, really?
Strict on the things a machine can check, which is most of them. The main image rules that get enforced are a pure white background, a resolution floor — commonly around 1,000 pixels on the longest side, above which zoom is enabled — and the product filling the large majority of the frame. Additional gallery images are usually far more relaxed and are where lifestyle and in-context shots belong. Verify the current numbers against the marketplace's own seller documentation before you automate against them; these were checked September 2026.
Can I process a thousand product photos?
Yes, in batches. Group calls into multicall requests so they run concurrently instead of serially — they are dispatched with a single parallel execution and the batch is billed once, up front, with any individual failures refunded automatically. There is no cap on batch size, which is exactly why you should impose one: a thousand-item request fires a thousand upstream calls at once. Twenty to fifty per batch, driven from a queue that records the resulting URL against each SKU, is the sane shape.
What does one product cost to process?
Twenty-four credits for the full treatment — 15 to enlarge, 8 to cut out, 1 to encode — or 9 if the source resolution already clears the marketplace floor and no enlargement is needed. Compositing onto white costs nothing because you do it locally. A thousand SKUs at the full treatment is 24,000 credits, so this is a job to size against a plan before you queue it.
Is this the cheapest way to remove a thousand backgrounds?
No. If cutouts are the only thing you need and you are doing them at real volume, a dedicated per-image cutout service will beat this by a wide margin — that is what a single-purpose product is for. This pipeline earns its place when the work per SKU is heterogeneous: enlarge this one, cut out that one, drop a third into a seasonal setting, and have an agent decide which is which. Paying for one integration instead of assembling four vendors is the argument, not unit price.
Is it legal to alter a supplier’s product photo?
That depends on your supplier agreement rather than on the tool. Most distribution agreements permit resizing and background normalisation for retail listings, and many require it. Editing the product itself — changing its colour, finish or proportions — is a different question, and one to settle with the supplier before you automate it.
Should I generate product photos rather than edit real ones?
For the product itself, no. A customer who receives something that does not match the picture will return it, and in many markets a materially inaccurate product image is a regulatory problem rather than a design choice. Generate the surroundings — lifestyle settings, backdrops, seasonal scenes — and keep the product a real photograph.
Will a cutout keep the product’s shadow?
Only where the shadow falls on the product itself. A contact shadow on the floor beneath it is part of the background and will usually go with it, which is normally what you want for a white-background listing — marketplaces generally expect the main image without one. If you want a shadow back for a lifestyle shot, it is more reliable to ask for it as part of the new setting than to try to preserve the original.
We use remove.bg today — does anything change?
remove.bg's own API documentation says that from 1 December 2026 its background removal moves to Leonardo.Ai, and points developers at a migration helper. Checked September 2026. If you are re-pointing a catalogue integration anyway, it is a reasonable moment to compare options — but check your own account for what happens to credits you have already bought, because that detail is not on their public docs.
Reference
Credit costs and encoder behaviour were read from the request handlers. The black-background result was reproduced directly against the encoder this API runs. Marketplace requirements are third-party and move — checked September 2026, and worth confirming against the seller documentation before you automate to them.