Ideogram Topaz Text Refine 8x limit: 8192px math vs Sume upscale
Ideogram rejects a Topaz Text Refine upscale if the output exceeds 8192px on a side. Work out the largest source per factor; Sume's upscaler takes 1 to 4.

Ideogram's Topaz Text Refine upscales 2x, 4x or 8x and is "rejected when the output would exceed 8192px on either side", so divide 8192 by the factor to get the longest source edge: 4096px at 2x, 2048px at 4x, 1024px at 8x. Sume's image upscaler takes an upscale_factor from 1 to 4, so 8x is not a single call there.
Ideogram facts are from its endpoint reference; Sume facts from the OpenAPI spec and Asset library, read 2026-10-01. The longer discussion of 8x is in the AI image upscaler 8x limit.
What are the Ideogram limits?
The endpoint is POST /v2/image/upscale/topaz-text-refine, multipart, with a source image up to 50MB. The 400 error is described as invalid input or an output over the 8K limit. It returns results directly by default; set async or a webhook_url to get a generation_id and poll.
| Factor | Longest source edge | Output at that edge |
|---|---|---|
| 2x | 4096px | 8192px |
| 4x | 2048px | 8192px |
| 8x | 1024px | 8192px |
What does the Sume upscaler accept?
POST /v1/image-upscale-1.0/upscale requires a public HTTPS image_url; upscale_factor is 1 to 4 (default 2) and output_format is png, jpg or webp. The spec states no output pixel ceiling, so test the largest size you need. In MCP the same job is image_upscale_create, a paid tool.
Which input URLs does Sume refuse?
Input URLs must be fetchable public HTTPS. The asset docs say localhost, private-network, non-HTTPS and signed or private URLs, and mismatched content types, are rejected before submission. An oversized request body returns 413 payload_too_large, and an input Sume cannot fetch surfaces image_not_fetchable or input_media_unreachable. Ideogram takes an upload instead; Sume takes a URL.
How do I reach 8x on Sume?
Chaining two calls (for example 2x then 4x) multiplies the factor, but the docs make no promise about quality after repeated passes, so inspect the result. See the image upscale API for the route and exact pixel size for hitting a target.
Sources
Related posts
More in Developers
- Idempotency-Key draft: 422 reuse vs Sume's 409 conflict
The IETF Idempotency-Key draft expired 18 April 2026 and uses 422 for a reused key; Sume returns 409 idempotency_conflict for a different body.
- IETF RateLimit-Policy draft vs Sume's ratelimit-* headers
The IETF RateLimit draft defines structured RateLimit-Policy and RateLimit fields. Sume sends plain ratelimit-limit, -remaining, -reset and retry-after.
- Inngest retries a failed step four times: key the Sume submit
Inngest's default is four retries after the first attempt, five in all, and side effects are not exactly-once. Give the Sume submit an Idempotency-Key.
- Inngest NonRetriableError and RetryAfterError for Sume errors
Map Sume HTTP errors to Inngest: NonRetriableError for 400, 401, 402 and 404, and RetryAfterError with the retry-after header on a 429.
Written by Sume