Cut out then upscale, or upscale then cut out? Order for PNG alpha

Do the upscale first and the background removal last. Sume's RMBG 1.0 returns mirrored PNG artifacts with alpha, and nothing in the docs says what Image Upscale 1.0 does with an existing alpha channel, so putting the cutout at the end of the chain means nothing downstream can flatten or drop the transparency.

The request fields below are from the Sume API routes and schemas; tool names are listed in MCP tools and gates. Jobs follow the usual job flow.

What does each Sume call take and return?

Image upscale is POST /v1/image-upscale-1.0/upscale with an image_url (public HTTPS), an optional upscale_factor between 1 and 4, and an optional output_format of png, jpg or webp. Background removal is POST /v1/rmbg-1.0/remove with an image_url; its description says completed results expose mirrored PNG artifacts with alpha. On hosted MCP the tools are image_upscale_create and rmbg_create.

Why is the order upscale first?

There are two chains. Cutout then upscale gives the upscaler an image with transparency, and the docs are silent on how it treats that. A JPG output would certainly lose the alpha, because JPEG has no alpha channel. If you do take this order, set output_format to png or webp and check the result yourself.

Upscale then cutout avoids the question: the upscaler sees an ordinary opaque photo, and RMBG's last step produces the PNG with alpha that you ship. The cost is that RMBG works on a larger image, which is a billing and time matter you can see on the catalog. I could not find a Sume document that says one order gives cleaner edges, so I do not claim that.

What happens with an input that is already transparent?

RMBG has a documented rule for this. When the input already has substantial fully-transparent pixels, which is typical when you re-cut an existing cutout, Sume flattens it onto mid-gray #808080 before sending it to the provider so edges stay clean. It is still one billed removal, and opaque inputs are unchanged. This is another reason to keep one cutout at the end of the chain rather than cutting twice.

# 1) upscale 2x, keep it opaque
curl -X POST https://api.sume.com/v1/image-upscale-1.0/upscale \
  -H "Authorization: Bearer $SUME_API_KEY" -H "Content-Type: application/json" \
  -H "Idempotency-Key: up-001" \
  -d '{"image_url":"https://example.com/product.jpg","upscale_factor":2,"output_format":"png"}'

# 2) use the upscaled artifact URL from the job result for the cutout
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: cut-001" \
  -d '{"image_url":"https://media.sume.com/artifacts/artf_up/product.png"}'

What about product photos on white?

Product shots on white are the easy case for the upscale-first order, because the input is opaque. Upscale 2x as PNG, cut out, and you have a transparent file at roughly four times the pixels. The scale factor is per side, so a 2x upscale quadruples the pixel count, and the image upscale reserves around 16 megapixels of output in its public pricing, so a very large source at 4x may exceed what you wanted to pay for.

If your source is already a cutout from some other tool and you want it bigger, you are in the other order by necessity. Then set output_format to png or webp and open the result to confirm the alpha survived. If it did not, flatten against a neutral color on purpose, upscale, and run RMBG again: the re-cutout rule means Sume will flatten transparent inputs onto mid-gray itself, so the edges should stay clean.

Whatever you choose, keep each artifact URL from the job results. They are durable Sume media URLs, so you can compare the two chains side by side on your own images, which is the only test that settles the edge-quality question for your content.

What should I check before shipping?

Budget two jobs. The image upscale reserves roughly 16 megapixels of output in its public pricing, and RMBG is billed per removal; confirm both in GET /v1/catalog.

• Open the final file and confirm the PNG really has alpha; do not trust the extension.
• Keep the artifact URL from the job result; both calls are async jobs you poll with GET /v1/jobs/:id/result.
• Use a new Idempotency-Key for each different operation; reuse one only to retry the same request.