Sume image upscale output_format webp: accepted, but you get a PNG

If you send output_format: "webp" to Sume Image Upscale 1.0, expect a PNG back. The request schema lists png, jpg and webp, but the upscale route's provider payload only distinguishes JPEG from PNG: jpg and jpeg become JPEG, and everything else, including webp, becomes PNG. Read the content_type on the artifact rather than trusting the format you asked for.

This post is based on the Sume OpenAPI request schema, read on 2026-10-02, and on the provider-payload builder for the image upscale route in the Sume repository, which carries a code comment saying the upscale model accepts JPEG and PNG only and that a public webp falls back to PNG.

What does the schema promise?

output_format is an enum of png, jpg and webp, described as "Output image format (default png)". The factor is upscale_factor from 1 to 4, default 2. Nothing in that description says WebP is treated differently from the other two, which is why the mismatch is easy to miss.

Sume's other image routes, such as image generation, do list png, jpeg and webp and can return a .webp artifact with media_type: image/webp, as the images model page shows for non-PNG formats. It is natural to assume the upscale route behaves the same way. On this route it does not.

What actually happens for each value?

From the payload builder:

Why does it matter for file size?

A PNG of an upscaled photograph is large. A 2x result is four times the pixels, and PNG is lossless, so a photo that was a 400 KB JPEG can come back as several megabytes. If you asked for WebP to keep a page light, or to stay under a platform's upload limit, the PNG you receive may be far bigger than you planned for.

Platforms that cap size are the usual place this bites. The related posts on WebP and JPEG for Google Merchant and on TikTok photo posts both start from the format a platform accepts and work back to what Sume returns.

What should I do instead?

Pick jpg when you want a smaller photographic file and do not need transparency, since the builder honours it. Keep png when the image has an alpha channel, because JPEG has none. If you need WebP specifically, upscale to PNG or JPEG and convert on your side with a tool you control, after you have checked the pixel dimensions you need.

Then verify the result. Poll the job, fetch the result, and assert on content_type and on the file's real dimensions before you publish. The script below reads a saved result and assumes the artifacts sit in an artifacts list as on the media inputs page; change the key if your result differs. A check like this catches a format surprise before it reaches a customer.

import json, sys

# usage: python check.py result.json image/jpeg
result = json.load(open(sys.argv[1]))
wanted = sys.argv[2]
for art in result.get("artifacts", []):
    got = art.get("content_type")
    status = "ok" if got == wanted else "MISMATCH"
    print(status, art.get("id"), got)
    if got != wanted:
        sys.exit(1)

Is this likely to change?

It could. The fallback is a comment in the payload builder, not a promise in the public schema, so a later change could add real WebP output or tighten the enum. Check the live OpenAPI document before you rely on this table, and treat the content type on the artifact as the source of truth.