Ideogram 4.5 pixel size to ratio: where 1920x1080 and 1600x500 snap

If you send image_size: "2400x1000" to Ideogram 4.5 on Sume, it is not used as pixels. It is snapped to the nearest of the 15 native ratios, here 2:1, and the output size comes from the ratio and the tier. The same goes for aspect_ratio given as a pixel string, so 1080x1350 becomes 4:5 and the file is 896x1120 at 1K.

Seven common sizes, resolved

I ran each size through the Sume size resolver on 2026-10-05, which makes no paid call. The last two columns show the pixels you receive at 1K on a text-to-image call and on an edit.

What this means in practice

• The returned size is never the size you typed. Your own code must resize or crop, and you should assert the returned width and height.
• Sizes that are far from a native ratio lose the most. A 1600x500 request is 3.2:1 and lands on 3:1, which is close, but 2560x1080 is 2.37:1 and lands on 2:1, which means a 16 percent crop to get back.
• At 2K the tiers double the 1K text sizes for every ratio except 1:3 and 3:1.

The 15 native ratios

1:3, 3:1, 1:2, 2:1, 9:16, 16:9, 10:16, 16:10, 2:3, 3:2, 3:4, 4:3, 4:5, 5:4 and 1:1. A colon ratio outside this list, such as 21:9, returns 400 with the supported values, while a pixel string is snapped. That difference surprises people who move between the two forms.

Edit calls and the source shape

Do not send a size at all if you want the edit to keep the shape of the source. Sume documents this in the Image API docs, and Ideogram's own edit reference says the output resolution matches the input (read 2026-10-05).

When not to rely on snapping

If you need a ratio outside the list as a hard requirement, do not depend on the snap. Pick a model that lists it, or generate at the nearest ratio and crop deliberately, so the loss is a decision rather than a surprise.