Nano Banana 2 banner ratios 4:1 and 8:1: Pro does not list them

For a wide banner on Nano Banana through Sume, use google/nano-banana-2. Its catalog list adds 4:1, 1:4, 8:1 and 1:8 to the ratios that Nano Banana Pro lists, and google/nano-banana-pro returns a 400 if you ask it for any of those four. The widest shape Pro offers is 21:9.

The ratio sets are the difference that matters for banners, so this post lays them side by side and shows the request.

Which ratios does each Nano Banana row list?

Both rows come from the Sume aspect-ratio catalog, and both include auto. The Nano Banana 2 list is Pro's set plus four extreme shapes, which a code comment in the repo describes as extreme banners.

What does Google's own page say?

The Google Nano Banana image generation page that I read lists ten ratios: 1:1, 3:2, 2:3, 3:4, 4:3, 4:5, 5:4, 9:16, 16:9 and 21:9. It does not list 4:1, 1:4, 8:1 or 1:8, and I could not confirm those four on it. Sume's Nano Banana 2 row does list them, so treat them as a Sume catalog fact and run one test call before you build a template around them.

The same page lists resolutions of 512px (labelled Flash only), 1K, 2K and 4K, and describes the 3.1 Flash model as the one with the smaller resolution option and expanded aspect ratio support compared with earlier versions. Nano Banana 2 is the Flash-class row on Sume, which is consistent with it carrying the larger ratio list.

How do I request a banner?

Send the ratio you want in aspect_ratio and a resolution tier in resolution. The Sume docs list tiers 512, 1K, 2K and 4K for Nano Banana, with 1K as the default. A strip at a higher tier costs more to generate and is likelier to pass the 30-second blocking budget, in which case the call returns a 202 job envelope instead of the image, so check the status code.

If you ask Pro for 8:1, the error carries the accepted list in supported, so your fallback can read it and drop to 21:9.

curl -sS https://api.sume.com/v1/images \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"google/nano-banana-2",
       "prompt":"Wide web banner, pale blue gradient, a paper boat on the left, empty space on the right for text",
       "aspect_ratio":"8:1",
       "resolution":"1K"}'
# 200 with data[0].url, or 202 with a job envelope; check the status code.

What are the limits of a very wide strip?

An 8:1 image is a thin band, so fine detail and text suffer first. Keep the prompt to one subject and one block of negative space, and add any headline in your layout tool afterwards instead of asking the model to draw it. If a headline must be rendered, a 4:1 strip leaves more height for letters than 8:1.

For ad networks that want fixed sizes, treat the ratio as the first step and resize or crop to exact pixels after. The Nano Banana Pro custom aspect ratio post explains how Sume treats a pixel size sent to the Nano Banana rows: it is mapped to the nearest native ratio, and exact pixels are a documented post-step, not something the model draws.

Which one should I pick?

Pick Nano Banana 2 for strips and tall pins. Pick Pro when you need its quality and a ratio up to 21:9 is enough. The Pro versus 2 comparison covers cost and speed; read cost_usd from the endpoints call for both before you commit to a batch.

How do I check the result?

Open the returned file and read its pixel dimensions, then divide width by height. For 8:1 you should land close to 8, and for 4:1 close to 4. If the number is off, the ratio was not applied as you expected, and you should compare it with the request you logged.

Keep the original and make a derived copy for each ad slot. Banner slots usually have exact pixel sizes, and those are produced by cropping or resizing after generation. Do that in your own image tooling so the original strip stays available for the next size you need.