The ratios the model was trained on, and what happens outside them

Why a tall image grows a second head

Ask an SDXL model for 1024 × 2048 and you will often get two torsos stacked, or a figure with an extra set of legs. This is not the model being stupid. It is a direct consequence of how it learned.

Training images are grouped into buckets: a fixed set of resolutions with roughly constant total pixel count. SDXL’s bucket list is built around 1,048,576 pixels, which is why the familiar sizes are:

• 1024 × 1024 (1:1)
• 1152 × 896 and 896 × 1152 (roughly 9:7)
• 1216 × 832 and 832 × 1216 (roughly 3:2)
• 1344 × 768 and 768 × 1344 (roughly 7:4)
• 1536 × 640 and 640 × 1536 (12:5)

Inside those, the model has seen thousands of examples of how a person fits the frame. Outside them, it has seen almost none, and its behaviour is an extrapolation. The specific failure (repeated subjects) happens because the network’s receptive field covers a certain span of the latent; stretch the canvas well beyond what it saw and two regions independently decide they are each looking at the centre of a portrait. You get two centres.

SD 1.5 has the same structure around 512 × 512 and degrades much faster outside it; anything past about 768 in either dimension repeats reliably. FLUX and other newer architectures are considerably more tolerant and will hold together at ratios SDXL cannot, but they still have a comfortable range and still degrade outside it.

The working rule

Generate at the nearest native bucket. Crop or extend to the delivery size afterwards.

Two worked examples:

• You need 1080 × 1350 (4:5) for Instagram. The nearest SDXL bucket is 896 × 1152 (7:9, which is 0.778 against your 0.8). Generate there, upscale to 1080 × 1389, crop 39 pixels. Nothing distorts.
• You need 1200 × 630 (1.905:1). The nearest bucket is 1344 × 768 (1.75:1). Generate there and outpaint the sides rather than cropping the top and bottom, because cropping a 1.75 frame to 1.9 throws away composition you wanted. Outpainting is covered later in the course, and this is the commonest reason to reach for it.

For a very wide or very tall final format, a roll-up banner at 1:2.35, a web skyscraper ad, do not try to generate it in one go. Generate the interesting part at a native ratio and extend outwards in steps. The result is coherent; the single-shot attempt is a stack of duplicated torsos.

Checking a model rather than trusting a table

Bucket lists differ between model families and the table above is only for SDXL. A four-minute test tells you any model’s real range: fix the seed and prompt, generate a simple single-subject portrait at 1:1, 4:5, 3:2, 16:9 and 2:1, and look at which ones hold. Write the answer next to the model in your notes. This is the sort of thing everybody re-learns from forum posts every few months and nobody measures once.

What this does not fix

Bucketing explains duplicated subjects at extreme ratios. It does not explain a duplicated subject at 1:1, which has a different cause: usually a prompt that describes a scene wide enough that the model reasonably renders several people, or a composition control pushing in two directions.

And there is an honest limit to the “generate native, crop later” rule. Cropping changes the composition the model chose. A frame that was well balanced at 3:2 can lose its subject’s breathing room when taken to 4:5, and the fix is not a better crop but generating with the final crop in mind, which is what the next lesson is about. Ratio arithmetic gets you a frame with no duplicated limbs. It does not get you a frame that still works after the crop.

Resolution is a separate question from ratio

People conflate the two and then generate a 2048 × 2048 image expecting more detail. Past the trained pixel count you do not get a more detailed picture; you get the same failure as an extreme ratio, because the canvas is again larger than anything the model composed for. A 2048-square SDXL render very often contains two horizons, two suns, or a subject assembled from two overlapping attempts.

The route to a large image is therefore always the same: generate at native size, then enlarge in a separate step. An upscaler (an ESRGAN-family model, which is free, tiny and needs no GPU worth speaking of) takes a good 1024 frame to 4096 without inventing a second horizon, because it is doing a different job. The finishing block covers what upscalers add and what they fabricate.

There is one partial exception. Some newer models handle larger canvases far better than SDXL does, and a few are trained at 1536 or 2048 natively. The test from the section above tells you which you have in four minutes. Do not assume from a version number.