Sume video upscale: scale_ratio overrides upscale_factor

If you send both scale_ratio and upscale_factor to Sume's video upscale route, scale_ratio wins. The schema says so in plain words: scale_ratio is "Scale ratio (default 2). Overrides upscale_factor when set", and upscale_factor is a "Scale ratio alias (default 2)". Both accept 1.1 to 4, and omitting both gives 2x.

The facts here come from the Sume OpenAPI request schema for POST /v1/video-upscale-1.0/upscale, read on 2026-10-02, and from the route's input handling in the Sume repository, which reads scale_ratio first, then upscale_factor, then falls back to 2.

Which field should I send?

Send one. upscale_factor is the name shared with Sume Image Upscale 1.0, so a client that handles both products can use a single field name. scale_ratio is the video-specific name. Because the video route accepts either, a wrapper that adds upscale_factor as a default can silently lose to a caller that passes scale_ratio, and the reverse cannot happen: the explicit scale_ratio always wins.

That matters in shared code. If a helper sets upscale_factor: 2 as a default and a teammate adds scale_ratio: 3 in a later call site, the job runs at 3x, which is the intent, but a log line that prints only upscale_factor will say 2. Log the whole body, or pick one field and enforce it.

What are the exact limits?

The schema gives these values.

Which ratio reaches which size?

Divide the target width by the source width. The table does the arithmetic for common cases, before any rounding the pipeline may apply to the output size.

Read the source size first with a probe, because a clip you believe is 720p is sometimes 1280 by 704 or a vertical 720 by 1280. A wrong guess means the ratio overshoots or undershoots the size a platform asks for.

What does the multiplier do to the picture size?

It multiplies both width and height, so a 1280 by 720 clip at 2 becomes 2560 by 1440 and at 3 becomes 3840 by 2160. A 1080 by 1920 vertical clip at 2 would be 2160 by 3840. At 1.5 a 720p clip becomes 1080p, which is often the sensible step when the platform you publish to tops out at 1080p.

Topaz's Video page for its Starlight Precise model lists minimum, 2x, 3x and 4x as its scale choices, read on 2026-10-02. Sume's 1.1 to 4 range is wider, so an in-between ratio such as 1.5 is possible on Sume. Neither page promises that a higher ratio looks better, so view the result at full size before you commit to 4.

How do I send it and what do I check?

Keep the clip within the 30-second duration_seconds ceiling, trim first if needed with video trim, and send duration_seconds close to the real length so the reservation matches. Use an Idempotency-Key, and poll the job instead of resubmitting after a slow wait, as the jobs page advises.

curl -X POST https://api.sume.com/v1/video-upscale-1.0/upscale \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: upscale-ratio-001" \
  -d '{
    "video_url": "https://media.sume.com/artifacts/artf_demo/clip.mp4",
    "scale_ratio": 1.5,
    "enhancement_tier": "standard",
    "duration_seconds": 12
  }'

What are the common mistakes?

A ratio below 1.1 or above 4 is rejected by the schema, so 1 and 5 fail. A duration_seconds above 30 fails too. Neither field is a target resolution: there is no width or height field, so compute the ratio yourself from the source size you read with video inspect. For the arithmetic on cost per second see the per-second price post.