Generating and Editing Images with Foundry Image Models
Generating and Editing Images with Foundry Image Models
Image generation produces a picture from a text description, and optionally from an existing picture you supply alongside it. It is one half of the vision area on this exam — the other being models that read images — and the two are easy to confuse. This note is about production: what the models are, what a call looks like, what comes back, and which guardrails sit around it.
Start with the model landscape, because it moved
The most common way to get this topic wrong is to study a retired model. DALL-E is no longer the answer. The dall-e-3 image generation model was retired in March 2026, it cannot be deployed, and deployments that already existed stopped working. The replacement family is the GPT-image series, and any current guidance points you there.
Within that family, availability differs. GPT-Image-2 is generally available and is the one aimed at high resolution, up to 4K, with improved editing and broad aspect-ratio support. GPT-Image-1.5 and GPT-Image-1 are limited access preview models pitched at realism, instruction-following and multimodal context, with 1.5 offering better speed and cost than 1. GPT-Image-1-Mini is also limited access preview and is the cheap, fast option for prototyping and bulk generation — with a real trade-off attached, since it has no dedicated face preservation and is better suited to general creative imagery than to portraits.
All of these accept both text and image inputs. None of them return a URL.
The shape of a generation call
You deploy a model, then post to the image generations endpoint for that deployment with a JSON body. The essential fields are the prompt, the model — set to your deployment name, not a generic family name — plus size, how many images you want, and a quality level. A successful response is a created timestamp and a data array containing at least one image object.
The single most important consequence of that response shape is that the image arrives as base64 data in a b64_json field. There is no URL to fetch. Code ported from older DALL-E samples that expects a link will break here, and the response_format parameter that used to switch between the two is not supported for the GPT-image-1 series at all. Decoding base64 and writing bytes to disk is now part of the normal path.
Generation is not instant, either. Expect roughly ten to thirty seconds depending on model, size and quality, and complex prompts can push toward a minute. Design your user experience around a wait rather than a round trip.
The options that actually change the output
Size behaves differently by model. The GPT-image-1 series takes one of three fixed sizes: a square, a portrait and a landscape, with the square being fastest. GPT-image-2 accepts arbitrary resolutions inside constraints — both edges a multiple of sixteen pixels, a long edge up to 3840, an aspect ratio no more extreme than 3:1, and a total pixel count inside a defined band. Those constraints only bind when you name a size; asking for automatic sizing can yield dimensions that fall outside them.
Quality offers low, medium and high, with lower settings generating faster; high is the usual default, while the mini model defaults to medium. You can request between one and ten images in a single call, defaulting to one. Output format is PNG or JPEG, defaulting to PNG, and WEBP is not supported. Compression applies only to JPEG output. A transparent background requires two settings agreeing with each other: the background option set to transparent and PNG output, since JPEG cannot carry transparency. A user identifier can be attached for usage tracking. Finally, streaming returns partial images as generation proceeds, with a small number of intermediate frames, which improves perceived latency without making the work finish sooner.
Editing, masks and fidelity
Editing modifies an existing image from a text instruction, and it differs from generation in a way that trips people up: the edit endpoint takes multipart form data, not JSON. The input image must be a PNG or JPG under 50 MB.
A mask turns editing into inpainting. The mask is a separate PNG whose fully transparent pixels mark the region you want changed, and it must match the input image's dimensions exactly. Get the dimensions wrong and the call is not merely inaccurate, it is invalid. Input fidelity controls how hard the model works to preserve the style and features of the input — faces especially — so that a small edit does not quietly redraw unrelated parts of the picture. That parameter is not available on the mini model.
Guardrails you are expected to know
A content moderation filter sits in front of these APIs. A prompt judged harmful simply does not produce an image, and the error code returned is contentFilter. Filtering also happens on the way out: a generated image can be blocked even when the prompt passed, with a distinct message saying so. Both directions are moderated, and both are worth remembering as a pair.
One special case is called out explicitly: photorealistic imagery of children is refused unless you have separately requested and been granted that capability. Alongside this sit ordinary operational limits — a modest default quota of images per minute per deployment, a 429 when you exceed it, and a 401 when a key is wrong or an identity lacks the right role.