image_size presets (landscape_16_9, square_hd): what Sume sends

If you send image_size: "landscape_16_9" or "square_hd" to the Sume Image API, the preset is accepted on every catalog row, but it does not travel the same way to every model. On models that take a fixed list of aspect ratios (Ideogram, Grok, Imagen, Nano Banana) Sume translates the preset into a ratio. On GPT Image 2.5 and the FLUX rows it is passed through under image_size.

The preset names are the ones a lot of image tooling already uses, which makes them handy when you port a request from another stack. This post lists what each preset becomes and the one case where auto surprises people. Every mapping below was read from the request normalizer on origin/main and exercised with test inputs, so it describes what Sume does now.

The preset-to-ratio map

Six named presets are recognised in addition to auto. They map to ratios like this, which is the table Sume applies for the models that only take a ratio. Note the naming: portrait_4_3 is 3:4 (tall) and landscape_4_3 is 4:3 (wide), and both 16:9 presets follow the same rule.

square and square_hd both become 1:1. On a ratio-only model the two are the same request: the output size then comes from the resolution tier, not from the preset name.

What auto does on each row

auto is the one value that is not a plain translation. On Nano Banana it stays auto, which is a ratio that model lists, so the provider chooses. On Ideogram, Grok and Imagen there is no auto ratio in their catalogs, and the normalizer turns a text-to-image image_size: "auto" into 1:1. On GPT Image 2.5 and FLUX it is passed through as auto.

The practical rule: if you want a specific shape, say so. Do not rely on auto for text-to-image unless you are happy with a square on the ratio-based rows. On an edit call with a reference, the docs recommend aspect_ratio: "auto" to match the reference shape, and say that omitting the field is not the same as auto (Sume Image API docs).

Check a preset before you ship it

The cheapest check is the catalog. A model's supported_parameters lists the aspect_ratio values it accepts, so you can confirm that the ratio a preset becomes is on the list for the row you picked. Grok, for example, does not list 4:5, so a preset never produces it, and sending a literal 4:5 is a 400.

The script below fetches the catalog and, for each model, reports which presets resolve to a ratio the model lists. It only reads the models endpoint, so it costs nothing to run. It needs SUME_API_KEY in your environment.

import os, requests

PRESETS = {"square_hd": "1:1", "portrait_4_3": "3:4", "landscape_4_3": "4:3",
           "portrait_16_9": "9:16", "landscape_16_9": "16:9"}
r = requests.get("https://api.sume.com/v1/images/models",
                 headers={"Authorization": f"Bearer {os.environ['SUME_API_KEY']}"}, timeout=30)
r.raise_for_status()

for m in r.json()["data"]:
    ratios = m["supported_parameters"].get("aspect_ratio", {}).get("values")
    if not ratios:
        print(f"{m['id']}: no aspect_ratio list (sizes handled via image_size)")
        continue
    ok = [p for p, ratio in PRESETS.items() if ratio in ratios]
    print(f"{m['id']}: {', '.join(ok) or 'no preset matches'}")

When to skip presets

Presets are a convenience for portability. If you control the request, a literal aspect_ratio such as 16:9 is clearer, and for GPT Image 2.5 you can send custom pixels as WIDTHxHEIGHT when both edges are multiples of 16. See images-api-size-vs-image-size-custom-pixels for how size and image_size differ, and image-api-aspect-ratios-and-custom-sizes for the ratio lists per model.

One more guard: size is a resolution-tier shorthand (512, 1K, 2K, 4K, 720p, 1080p), not a place for pixels or presets. Put shape in image_size or aspect_ratio, and tier in resolution.