Sume ignores aspect_ratio when image_size is set: Flux, Seedream

On Sume's custom-pixel image rows, image_size wins and aspect_ratio is ignored. Nano Banana turns WxH into an enum ratio. What each model does with both fields.

5 min readSume
All posts

On Sume's custom-pixel image rows, image_size wins when you send both fields, and aspect_ratio is ignored. The docs name those rows as GPT, Seedream, Flux, Qwen and Recraft. On Nano Banana, image_size is handled differently: a WxH value is mapped to the closest native aspect_ratio, so 1080x1350 becomes 4:5. Send one field, not both, so the intent of your request is unambiguous.

What each model does

Sume's Image 1.0 docs say image_size takes named presets or { width, height } or WIDTHxHEIGHT on models that accept custom pixels, and that those models ignore aspect_ratio when image_size is set. The OpenAPI text for the /v1/images field agrees that image_size wins over aspect_ratio. Pixel rules apply when the size is custom: GPT rows validate against the box with both edges as multiples of 16.

How image_size and aspect_ratio combine, as of 2026-10-08
Row familyaspect_ratio onlyimage_size set
GPT Image 2 and 2.5Ratio from the GPT list (4:5 expands to 1024x1280)image_size wins; custom pixels validated
Seedream, Flux, Qwen, RecraftRatio from the row's listimage_size wins; aspect_ratio ignored
Nano Banana 2.1 and ProNative enum ratioWxH maps to the native aspect_ratio; exact pixels come from a post-step
Imagen 4, Soul, GrokRatio from the row's listCustom pixels not advertised

A request that sends both

The body below asks for 16:9 and also for a square. On a Flux row the square wins, and the ratio field has no effect. The response will not warn you, so a copied template that carries a leftover aspect_ratio can hide this.

{
  "model": "black-forest-labs/flux.2-pro",
  "prompt": "A lighthouse on a cliff at dusk",
  "aspect_ratio": "16:9",
  "image_size": {"width": 1024, "height": 1024}
}

Edits use a third rule

On edit and image-to-image calls, aspect_ratio set to auto matches the reference image. If you omit the field, the result is not the same as auto. That distinction matters for a photo edit where you want the source shape kept. For Ideogram 4.5, an edit without aspect_ratio keeps the shape of the source image, as its docs state.

So the safe habit is to decide up front: exact pixels, use image_size and no ratio; a standard shape, use aspect_ratio and no size; keep the source shape, use aspect_ratio auto where the row lists it.

Validate before you send

Reject bodies that carry both fields in your own client. It costs one line and removes a class of silent surprises.

The simplest rule for a shared client is to hold one source of truth for shape. Store either a ratio or a pixel size per request, never both, and build the body from that one value. If a user has set a ratio and then types a size, clear the ratio field in your own state. This keeps your logs honest too: a log line that shows both fields suggests both were used, when only one of them was.

def check(body: dict) -> None:
    if "aspect_ratio" in body and "image_size" in body:
        raise ValueError("send aspect_ratio or image_size, not both")

check({"aspect_ratio": "16:9"})
try:
    check({"aspect_ratio": "16:9", "image_size": "1024x1024"})
except ValueError as e:
    print("blocked:", e)

Sources

Related posts

More in Developers

All Developers posts

Written by Sume