The 16:9 frame that gets refused
Ask an image endpoint for a 16:9 frame at roughly 1K and the obvious request is
1024x576. Long edge 1024, correct ratio, both numbers round. It is
refused.
1536x864 is accepted. So is 1280x720. The difference is
not the ratio and not the long edge, and working out which rule you broke is harder
than it should be because there are three of them and the error names one.
The three rules, measured
| Rule | What a violation looks like |
|---|---|
| Both edges divisible by 16 | 1000x1000 → must both be divisible by 16 |
| Long edge ≤ 3840 | 4096x1024 → must be less than or equal to 3840 |
| Widest frame is 3:1 | 2048x512 → maximum supported aspect ratio is 3:1 |
| A minimum pixel budget | 1024x576 refused; 1024x640 accepted |
1024x576 passes the first three. 576 is divisible by 16, the long edge
is well under the cap, and 16:9 is nowhere near 3:1. It fails the fourth — a floor on
total pixels that nothing in the parameter description mentions, and that you can only
find by bisecting the short edge.
Why a formula does not work here
The tempting fix is to compute the frame: take the tier's long edge, divide by the ratio, round to a multiple of 16. That satisfies the first three rules and silently fails the fourth at exactly the aspect ratios people use most.
So the frame has to be a lookup table, one cell per tier × ratio, with each cell checked once against the live endpoint. It looks redundant next to a two-line formula and it is the only version that works. The cost of the table is that somebody has to maintain it; the cost of the formula is a 400 at request time on the shapes your users pick first.
The enum and the pixel pair disagree
There is a second way to state a shape — an aspect_ratio enum — and the
two do not cover the same space. The enum runs out to 4:1 and
8:1, which explicit pixels refuse; explicit pixels reach 3:1,
which the enum has no member for. Asking for both at once is refused outright:
size "1024x1024" conflicts with aspect_ratio "16:9".
Pick one and send only that. We resolve to pixels and never send the ratio, because pixels are the form that can express every cell of the table.
The detail worth stealing
OpenAI's own worked example for a 16:9 slide asks for 1536x864. If you
are building a preset list, start from the frames the vendor publishes in its own
examples rather than from the ones arithmetic suggests. Where the two disagree, the
published one is the one their users have already tried.
The full tier × ratio table we ended up with, and the prompts that were run at each, are published at gptimage25.top/prompts.