Bria increase_resolution (2x or 4x, 8192 px) vs Sume image upscale

Bria's increase_resolution endpoint accepts only two multipliers, 2 or 4, and works up to a total area of 8,192 by 8,192 pixels. Sume Image Upscale 1.0 accepts an upscale_factor anywhere from 1 to 4 (default 2), so a 3x or a 1.5x is possible there and not on Bria.

Bria's side comes from its Increase Resolution page, read on 2026-10-02. Sume's side comes from the Sume OpenAPI for POST /v1/image-upscale-1.0/upscale, which the MCP tool list exposes as image_upscale_create.

What does Bria's increase_resolution do?

The page lists image (required, as base64 or a public URL; JPEG, JPG, PNG or WEBP in RGB, RGBA or CMYK), desired_increase (2 or 4), preserve_color, preserve_alpha, sync (default false), webhook_url and optional content-moderation flags. The response carries an image_url.

The page also draws a line between this route and its Enhance Image route: increase_resolution "does not add new details" and uses a dedicated upscaling method that preserves the original content without regeneration. That is a statement about Bria's endpoint, and it does not transfer to other products.

What does Sume Image Upscale 1.0 take?

The Sume request has an image_url (public HTTPS), upscale_factor between 1 and 4 (default 2), output_format of png, jpg or webp (default png), optional metadata, and the shared mode, webhook_url and wait_timeout_seconds fields. The schema refuses unknown fields and does not accept provider model ids.

Sume's catalog describes the job as one image upscale with a reservation of about 16 megapixels of generative output, which matters for the price you see in GET /v1/catalog. The description wording is "generative output", so do not assume the pixels are never invented; if exact fidelity matters, compare the result against the original at full size.

How do the limits compare?

Both columns list only what the vendor states.

How do I choose a factor on Sume?

Work backward from the target. For a 1600 px wide source that must reach 4000 px, 2.5 is the exact factor: 1600 x 2.5 = 4000. On Bria you would choose 4 and scale down afterwards, or choose 2 and accept 3200. On Sume, pass upscale_factor: 2.5 and keep the file size lower than a 4x result.

Remember that the factor is a multiplier on both sides, so 2x is four times the pixels and 4x is sixteen times. A 3000 by 2000 source at 4x is 12,000 by 8,000, which is 96 megapixels; Bria's 8,192 by 8,192 limit would refuse that. Sume's schema states no limit, so test large inputs before building a batch on them. Our exact-pixel-size post works through the arithmetic when you need a precise width.

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: upscale-img-001" \
  -d '{
    "image_url": "https://media.sume.com/artifacts/artf_demo/photo.jpg",
    "upscale_factor": 2.5,
    "output_format": "png"
  }'

What about output format and transparency?

Bria offers preserve_alpha for images with transparency. Sume's request has no alpha switch, only output_format. If your source is a transparent PNG, keep the output as png: a JPEG has no alpha channel, and Sume's schema does not promise to carry transparency across formats. Our WebP note explains why asking for WebP is not the same as getting it.

Plan the whole chain before you pay for it. A photo that needs a clean cutout and a 2x upscale should be cut first and upscaled second, or the reverse, depending on the result you want; the two orders give different edges. Run one sample each way and keep the better one before batching.

Is there anything to watch for in the result?

Poll the job, read the result URL, and store the Sume-owned artifact URL, not any provider link. If you combine this with background removal, the order post covers which step goes first. For price, read the live rate from the catalog rather than from a blog post, because rates change.