GPT Image 2.5 edit changed shape? Use aspect_ratio auto on Sume

On Sume edit and image-to-image calls, aspect_ratio auto is not the same as leaving the field out. How to read the model descriptor and keep the photo's shape.

5 min readSume
All posts

On Sume, an edit or image-to-image call should carry aspect_ratio: "auto" when you want the result to match your reference, because the Image API docs say that omitting the field is not the same as auto. Read the model's supported_parameters first to confirm that auto is listed for the id you are calling.

Everything here comes from Sume's Image API page. Where the docs do not say what an omitted field does, this post does not guess; it tells you how to find out for your own model with one request.

What exactly do the docs say?

Two lines matter. In the resolution section: "On edit and image-to-image calls, prefer aspect_ratio: \"auto\" to match the reference — omitting the field is not the same as auto." And in the parameter list: auto hands the choice to the provider. For GPT Image 2.5 specifically, image_size also accepts auto, named presets, or custom pixels with both edges multiples of 16.

Which option should I pick?

The table lays out the choices from the docs. It makes no claim about what the output will be when a field is omitted, because the docs do not state it.

Shape controls on an edit call (Sume Image API docs, read 2026-10-02)
SettingWhat the docs sayUse it when
aspect_ratio: autoMatches the reference; the provider picksYou want the edit to keep the photo's shape
aspect_ratio omittedDocumented as not the same as autoOnly if you have tested your model's default
aspect_ratio: 4:5 and so onA normalised ratio from the catalog listYou need a fixed channel shape
image_size: WxHCustom pixels on GPT models: edges x16, max edge 3840, ratio at most 3:1You need exact pixels

How do I confirm what my model accepts?

Ask the catalog before you pin a value. The per-model endpoint record lists the definitive parameter set, and a parameter the model does not list is rejected with 400 unsupported_parameter rather than dropped silently.

curl "https://api.sume.com/v1/images/models/openai/gpt-image-2.5/endpoints" \
  -H "Authorization: Bearer $SUME_API_KEY"

What does a safe edit request look like?

One reference, auto, and the constraint sentences from your prompt. If the result is still the wrong shape, switch to an explicit image_size and compare. Each completed image is billed, so change one thing between runs.

curl -X POST "https://api.sume.com/v1/images" \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-image-2.5",
    "prompt": "Image 1 is the photo to edit. Brighten the sky. Keep everything else exactly as it is.",
    "aspect_ratio": "auto",
    "input_references": [
      {"type": "image_url", "image_url": {"url": "https://example.com/photo.jpg"}}
    ]
  }'

What if I need an exact size afterwards?

Exact pixels such as 1080×1350 are not a multiple-of-16 size, so for GPT Image 2.5 request a nearby valid size and crop. The pre-flight rules are in the size validator post. For re-rendering at a different ratio on purpose, see the aspect ratio changer.

What does a failed shape check look like?

Compare the width and height of the result with the source. If the source is 4:3 and the result is square, the shape was not matched, and the next run should pin either auto or an explicit image_size. Keep the test image small and cheap: the low quality setting is enough to check shape.

Because the docs do not say what an omitted field does, do not rely on it in production code. Pin the value you tested, and re-run the check when you change models.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume