Exact 1080x1350 from Sume: ask for 4:5, then resize

To get an exact 1080 by 1350 image from Sume, request aspect_ratio: "4:5" from a model that lists it, then resize the result to 1080 by 1350 in your own code. Treat the ratio as what the model produces and the pixel size as what you finish, rather than expecting the API to return exact pixels.

The Image API docs note that 4:5 is Instagram portrait (1080 by 1350) and not 4:3, and that Nano Banana Pro's native 4:5 output is about 928 by 1152 at 1K. That is the gap the resize closes.

Who lists 4:5

Most of the 19 catalog ids list 4:5 as an aspect ratio; Grok Image does not. The ones that matter most for edits are below, with the base price per image, read from the catalog on 2026-10-10.

Resize without distortion

A 4:5 image resized to 1080 by 1350 keeps its shape, because 1080 divided by 1350 is exactly 0.8, the same as 4 divided by 5. If the returned image is a few pixels off 4:5, ImageOps.fit crops the smallest amount needed and then resizes, so nothing is stretched. The sample builds a stand-in image so you can run it as is; replace it with the file you downloaded.

from PIL import Image, ImageOps

# Stand-in for a downloaded 4:5 result, e.g. about 928x1152 from a 1K render.
im = Image.new("RGB", (928, 1152), (200, 120, 90))

out = ImageOps.fit(im, (1080, 1350), method=Image.LANCZOS)
print(out.size, round(out.size[0] / out.size[1], 4))
out.save("post-1080x1350.jpg", quality=92)

Upscale first when the source is small

Going from about 928 by 1152 to 1080 by 1350 is a 16 percent enlargement, which a Lanczos resize handles well. If you need a much larger size, for print or a 2x crop, ask the model for a higher tier where it has one (Nano Banana models list 2K and 4K). The order of upscale and edit is covered in a separate post.

Check before you resize

Read the real size of every download before you resize, because a 4:5 request is a shape promise and the pixel count depends on the model and tier. A Nano Banana model at 1K returns a smaller canvas than the same request at 2K, and a Seedream or FLUX model decides its own size from the ratio. If the returned frame is already at least 1080 by 1350, ImageOps.fit shrinks it and you lose nothing visible. If it is smaller, the resize enlarges it, and a soft result is the cue to choose a higher tier next time.

Log the source size and the final size together with the model id. When a batch looks soft, that single line tells you whether the cause was a small render or a bad prompt, and it costs you nothing to keep.

Things not to rely on

Do not rely on a pixel size field. size is a shorthand for a resolution tier, and the docs say explicit pixel sizes are not served on it in v1; a request that sends one returns 400 unsupported_parameter. Also do not build on target_pixels. The docs mention it as a post-step for exact pixels, but it is not applied, so the resize in your own code is the step that sets the final size.

• Check Image.open(...).size after every download and log it.
• Pick a model that lists 4:5, or Sume returns 400 invalid_request with the supported values.
• Export JPEG at quality 90 or so for the feed; keep a PNG master if you plan more edits.