Implement a solution that generates images from text prompts and reference media

Image generation looks like one API call, and most of the exam content sits in the constraints around it: which model supports which size, which parameter combinations are legal, and what the response actually contains. These are arbitrary facts by design — they are the part of the skill that cannot be reasoned out.

Why This Matters

Size rules differ by model family. The gpt-image-1 series takes three fixed sizes. gpt-image-2 takes arbitrary resolutions under four simultaneous constraints. A scenario naming an unusual aspect ratio has already chosen the model.

Some parameters have hard dependencies. background: transparent requires output_format to be png and is gpt-image-1 only. output_compression applies to JPEG only. Getting a dependency wrong is a failed request, not a degraded image.

The response is base64, not a URL. The gpt-image-1 series models always return base64-encoded images, which changes how the application handles output.

Prerequisites

• What a deployment is, and that image models have their own quota.
• Base64 encoding of binary data.
• PNG against JPEG: lossless with alpha, against lossy without.
• That content filters apply to prompts and to generated output.

Learning Objectives

By the end of this lesson you will be able to:

1. Choose an image model from a size, transparency, or fidelity requirement.
2. Set quality, output_format, output_compression, and background correctly.
3. Use reference media with input_fidelity.
4. Handle the base64 response and streaming with partial_images.
5. Anticipate rate limits and moderation behaviour.

Building Blocks

The models and their sizes.

Core parameters.

• quality — low, medium, high. Default high for GPT-Image-2, 1.5, and 1; medium for GPT-Image-1-Mini.
• output_format — png or jpeg, default png. WEBP is not supported.
• output_compression — integer 0 (no compression) to 100 (maximum), default 100, and it applies to JPEG output only.
• background — auto or transparent. Transparent requires output_format: png and is GPT-image-1 only.
• input_fidelity — "controls how much effort the model puts into matching the style and features, especially facial features, of input images". Set high to preserve faces more accurately. Not supported by gpt-image-1-mini.
• n — how many images to return.

Streaming. stream: true with partial_images between 1 and 3 returns intermediate images before the final result. Supported by the GPT-image-1 series and GPT-image-2.

The response. {"created": ..., "data": [{"b64_json": "..."}]} — the GPT-image-1 series models always return base64-encoded images, not URLs.

Rate limits. Default quota is 5 images per minute for both the GPT-image-1 series and GPT-image-2.

Deep Dive

The size decision

Two families, two rules, and the requirement usually names one.

The gpt-image-1 series accepts exactly 1024x1024, 1024x1536, and 1536x1024 — square, portrait, landscape. Anything else is rejected. That is fine for most product and avatar work and impossible for a banner.

GPT-Image-2 accepts arbitrary resolutions, but four constraints apply simultaneously:

• Both edges must be multiples of 16 px.
• Long edge up to 3,840 px — 4K.
• Aspect ratio up to 3:1.
• Pixel count between 655,360 and 8,294,400.

Each one rejects a plausible request. A very wide banner can satisfy the edge and pixel rules and still break the 3:1 limit. A 4K-long-edge image at an extreme ratio can exceed the pixel ceiling. And an otherwise reasonable size like 1000×1000 fails simply because 1000 is not a multiple of 16.

The practical implication for an application is to validate the requested size before calling rather than surfacing an API error to the user, since all four rules are checkable locally.

Parameter dependencies that fail requests

Three combinations are examinable because they are easy to get wrong.

Transparency. background: transparent needs two things: output_format set to png, and a GPT-image-1 model. JPEG has no alpha channel, so the format requirement is not arbitrary — but the model restriction is, and it is the half people forget. A requirement for transparent product cutouts therefore constrains the model and the format, and rules out gpt-image-2 even though it is otherwise more flexible.

Compression. output_compression is an integer from 0 (no compression) to 100 (maximum), defaults to 100, and applies to JPEG output only. Setting it alongside PNG output does nothing useful.

Fidelity on mini. input_fidelity is not supported by gpt-image-1-mini. A workflow that must preserve a reference image's style — especially faces — cannot use the mini model, whatever its cost advantage.

Reference media and input fidelity

Generation from a text prompt alone gives no control over style continuity. Supplying reference media with input_fidelity does.

The parameter "controls how much effort the model puts into matching the style and features, especially facial features, of input images". Set high, it "preserves faces more accurately than standard mode" and "enables subtle edits to an image without changing unrelated areas".

That second phrase is worth noting because it links generation to editing: high input fidelity is what keeps the untouched parts of an image untouched, which is exactly the property an editing workflow needs. The trade is compute and adherence — the higher the fidelity to the reference, the less freedom the model has to follow a divergent prompt.

The elimination to remember: mini does not support it. A brand-continuity or face-preservation requirement removes the cheapest model from consideration.

Output handling, streaming, and throughput

Three operational details shape the application.

The response is base64. data[0].b64_json carries the image, and the GPT-image-1 series models always return base64, not URLs. The application must decode and store it — there is no link to hand to a browser — which makes storage and lifecycle an explicit design decision rather than something the service handles.

Streaming shows progress. With stream: true and partial_images set between 1 and 3, intermediate images arrive before the final result. This is a perceived-latency control for interactive use; it does not make generation faster. It is supported by the GPT-image-1 series and GPT-image-2.

Throughput is low by default. 5 images per minute is the default quota for both families. Any bulk workflow needs either a quota increase or a queue — and a design that fans out image generation across many concurrent users will hit this before it hits anything else.

Worked Examples

Example 1 — transparent product cutouts. A catalogue needs generated product images with transparent backgrounds for compositing.

background: transparent, which requires output_format: png and is GPT-image-1 only. gpt-image-2 is more flexible on size but does not support transparency, so the size flexibility is irrelevant here — the transparency requirement decides the model.

Example 2 — a wide banner. Marketing needs a 3,840 × 1,024 banner.

GPT-Image-2, since the gpt-image-1 series accepts only three fixed sizes. Check all four constraints: both edges are multiples of 16, the long edge is exactly the 3,840 px ceiling, the ratio is 3.75:1 — which exceeds the 3:1 limit, so this request is rejected. Reducing the long edge or increasing the short edge to reach 3:1 (for example 3,072 × 1,024) satisfies it.

Example 3 — cheap generation with face preservation. A team wants the mini model for cost, and must preserve facial features from a reference image.

Not possible on mini: input_fidelity is not supported by gpt-image-1-mini. Use another model in the series or GPT-Image-2. Note also that mini's default quality is medium where the others default to high, so cost comparisons that ignore quality settings are misleading.

Visual Explanations

Model choice driven by the hard requirement:

The four GPT-Image-2 size constraints, all at once:

Common Mistakes

Assuming any model can produce a transparent background. GPT-image-1 only, with PNG.

Setting output_compression on PNG output. It applies to JPEG only.

Requesting WEBP. Not supported.

Choosing a size that is not a multiple of 16. One of four simultaneous constraints.

Checking aspect ratio but not the pixel ceiling — or the reverse.

Using mini where reference fidelity matters. input_fidelity is unsupported there.

Comparing costs while ignoring that mini defaults to medium quality.

Expecting a URL in the response. The GPT-image-1 series always returns base64.

Retrying a moderation refusal. The same prompt gives the same result and consumes quota.

Practice Exercises

1. State the four GPT-Image-2 size constraints and give a request that fails exactly one.
2. What two things does background: transparent require?
3. What does input_fidelity do, and which model does not support it?
4. What does the response contain for the GPT-image-1 series, and what does that mean for the application?
5. Which parameters control output size on disk, and where does each apply?

Summary & Concept Map

Image generation is a small API with sharp edges. Model choice follows the hard requirement: transparency means GPT-image-1 with PNG, an unusual size means GPT-Image-2 under four simultaneous constraints — edges multiples of 16 px, long edge to 3,840 px, ratio to 3:1, pixels 655,360–8,294,400 — and reference fidelity rules out mini, which alone lacks input_fidelity and alone defaults to medium quality. Format parameters carry dependencies: output_compression is JPEG only, background: transparent needs PNG, and WEBP is unsupported. Operationally, the GPT-image-1 series always returns base64, stream with partial_images 1–3 improves perceived latency without changing total time, throughput defaults to 5 images per minute, and moderation applies to prompts and outputs alike.

Sources and freshness

Written against current Microsoft Learn documentation for the AI-103 skills measured (16 April 2026), reviewed 2026-08-20. Microsoft Learn controls every changing product contract — availability, preview status, quotas, limits, regional support, naming, and retirement dates all move independently of this lesson. Where a scenario turns on a specific number or a GA/preview boundary, confirm it against the product's own page before relying on it.