From Request to Image: The Shared Generation Pipeline
This chapter follows one AUTOMATIC1111/stable-diffusion-webui request from its interface boundary to a saved or returned image. The useful question is not which function is called first, but which state changes at each stage: a request becomes a processing object, text becomes conditioning, a sampler produces a latent result, decoding makes it visible, and post-processing plus metadata determine what finally leaves the system. Once that sequence is clear, a reader can place a new setting in the pipeline instead of guessing from its label.
The path is shared by interactive work and automation. The Gradio UI gathers values from controls, while the FastAPI interface validates structured requests and can carry images, script arguments, or previously recorded generation information. They present different surfaces, but they hand the runtime the same kind of processing contract. That shared contract is what makes AUTOMATIC1111 a system rather than a collection of unrelated tabs.
A request becomes a processing object
The runtime represents a generation job with a common processing object. It contains the choices that define the job: positive and negative prompts, styles, seeds and variation settings, sampler and scheduler, width and height, batch size and iteration count, optional high-resolution or refiner settings, extension arguments, and rules for saving results. Text-to-image and image-to-image use specialized forms of this object. The distinction between them is real, but they share enough structure that the later stages can be coordinated by one processing loop.
This is a better mental model than treating every control as an independent switch. Width and height affect the shape of the work. A seed selects a path through variation. A sampler determines how the latent state is updated. A style changes the text that will be conditioned. A saving option changes persistence rather than the image-generation calculation itself. These choices can interact, but they do not all act at the same moment or own the same state.
The object is assembled differently depending on who is asking for the work. In the UI, a user presses Generate after filling controls, and the interface passes those values to the text-to-image or image-to-image function. In the API, a request is validated as a structured model. Images are represented as Base64 data, and a request can ask the service to return images, save them, run a named script, or supply arguments to an always-on script. The API can also use infotext to fill fields that were not explicitly supplied in the request. That makes a generated image a possible input to a later automated job, not just a final display object.
The two routes share an operational boundary as well. UI GPU calls and API calls use the same queue lock, so requests do not independently manipulate the model at the same time. Progress information tracks whether work is queued, active, or complete and can include an estimated progress value and a live preview. The UI may render that information as a gallery and progress bar; an API client may poll it. The presentation differs, but the model-facing work remains one coordinated job.
That state has a clear direction. A request is first pending, then becomes the active job, then either produces a result or is interrupted, skipped, or reported as an error. The queue owns admission order; the processing object owns the generation choices; the shared state reports job and sampling progress; and the output layer owns persistence and serialization. Keeping those responsibilities separate prevents a progress display from being mistaken for proof that sampling succeeded, or a returned image from being mistaken for proof that it was written to disk. It also explains why an API client should wait for completion rather than assume that submission means the model is already running.
The request boundary has its own failure conditions. An API image must be decodable, a named sampler or script must be resolvable, and a required initial image must exist for an image-guided request. A UI request can fail for a different reason if its controls are not initialized or its selected extension cannot be loaded. These are not alternative explanations for the same symptom: validation, queue admission, model processing, and output serialization are different transitions. The shared pipeline gives them a common vocabulary, but it does not make every failure a prompt problem.
That convergence does not remove the earlier boundaries. Environment preparation happens before the request can run. Model and script initialization happen before the processor can use them. A request can therefore fail before sampling if the runtime is not prepared, or during processing if a selected control cannot be resolved. The project’s architecture makes those stages visible enough to distinguish “the browser did not submit the job,” “the request was queued,” and “the generation stage did not complete.” A useful diagnosis starts by locating the failed transition rather than changing prompts at random.
The route from words to a recorded image
Once the processing object exists, the runtime prepares the information that the model will use. It expands a prompt across the requested batches and iterations, applies selected styles, and creates positive and negative conditioning. Conditioning is the model-facing representation of the text request. In AUTOMATIC1111 it can be more structured than one fixed sentence: parentheses or explicit weights can adjust attention, scheduled syntax can replace part of a prompt at a chosen sampling point, and AND can split a request into weighted components. The parser builds those conditions before the sampler begins its work.
This distinction prevents a common misunderstanding. The prompt does not directly specify pixels. It supplies text that is transformed into conditioning, and the sampler consults that conditioning while it moves through a sequence of latent states. A prompt schedule can therefore change the condition during the run. A negative prompt supplies another condition rather than acting as a guarantee that an unwanted feature can never appear. A style expands the text before conditioning rather than applying a visual filter after the image exists.
Conditioning is also a place where the runtime can reuse work, but only under specific conditions. AUTOMATIC1111 caches a conditioning result when the required prompts, sampling steps, model, dimensions, extra-network data, and relevant settings match. Change one of those inputs and the old result is no longer the same computation. This is a small but important example of hidden coupling: a setting that looks unrelated to the words can invalidate the representation the sampler receives. It also shows why a processing recipe needs more than the visible prompt if the reader wants to understand or compare a run.
The runtime also resolves variation. If the user leaves the seed at its special “choose one” value, AUTOMATIC1111 generates a seed for the job. If a seed is supplied, the runtime derives the per-image seed values used across a batch, with subseeds and variation strength available as additional controls. This is why a batch can contain related but distinct results without requiring a separate request for every image. The seed is an input to the random state; it is not a description of the picture and cannot replace the model, prompt, sampler, dimensions, or other settings.
The sampler receives the conditioning and the seeded starting variation and produces a latent sample. A latent is a compact internal representation that the runtime can manipulate before converting it into ordinary image pixels. The sampler and scheduler determine the path through that representation, which is why changing them can alter results even when the text and seed stay fixed. The processing loop can also expose progress during this stage and, where configured, turn an intermediate latent into a live preview. A preview is feedback about an unfinished state, not an additional final result.
Batching adds another layer to the same mechanism. The runtime expands the prompt and negative prompt into per-image values, pairs them with per-image seeds and subseeds, and processes those values in batches and iterations. A batch is therefore a coordinated set of related jobs, not one image copied several times. The output record keeps the collection of prompts, seeds, and infotexts aligned with the images. If generation is interrupted, the state and saving rules determine what can be shown or retained; an incomplete preview and a completed, recorded output are different states.
Decoding is the transition from a latent result to an image that can be displayed or written to disk. It is not necessarily the last transformation. The processing loop can apply face restoration, color correction, extension post-processing, mask overlays, and compositing before saving. The API also exposes separate extras operations for image enhancement. The distinction matters when evaluating a result: a visible change after decoding may come from a restoration or composite stage, not from the sampler that produced the latent.
Persistence has two audiences. A UI user needs an image that appears in the gallery, while an automated caller may need a Base64 response, a structured information string, a disk file, or some combination. The runtime can save the image through a temporary path and replace the destination atomically, reducing the chance that another process observes a half-written file. That implementation detail matters when a folder is being watched by another tool: “the job finished” and “a complete file is available” are related transitions, not the same event.
Consider a simple request containing a prompt, a negative prompt, a style, a seed, a sampler, an image size, and a request for one result. The UI or API first turns those values into the processing object. The runtime applies the style and prepares the two text conditions. The sampler uses those conditions and the seed to produce a latent result. The decoder makes an image. If no later transformation is selected, that image can be saved or returned; if restoration or an extension is active, the image passes through those stages before the final write. The runtime then assembles the generation information that belongs to that output.
That information includes the prompt and negative prompt, steps, sampler, scheduler, guidance scale, size, seed, variation values, denoising strength when relevant, and optional model or VAE names and hashes. Extra parameters can be added by the base runtime or by extensions. When image information is enabled, the writer places generation data in PNG text fields and uses supported metadata paths for other formats. The interface and API can parse that text back into controls. This turns persistence into a round trip: the image can carry enough of the recipe to become the starting point for another decision.
The round trip has a boundary. Reusing a seed and reading the stored parameters does not guarantee bit-for-bit identity after a model file, software version, extension, precision path, or device backend changes. The record narrows the causes that need investigation, but it does not freeze every condition in the surrounding system. A responsible reading of infotext is therefore, “these were the recorded inputs and options,” not, “the same output must always follow.”
That qualification is useful even when the goal is not exact reproduction. If a result looks wrong, the recorded sampler, size, seed, and model identity can support a focused comparison. If the image is right but the file is missing, the problem belongs to output handling rather than conditioning. If the file exists but the visible result differs after a restoration step, the post-processing boundary deserves attention. The pipeline does not eliminate judgment; it makes judgment more specific by tying an observation to the state and transition that could have produced it.
The same stage-based view gives each control a proper home. If the goal is a different interpretation of the prompt, begin with conditioning or the seed. If the goal is a comparable sampling path, hold those inputs steady while changing the sampler or scheduler. If the goal is to preserve or revise an existing image, the request must supply different starting information; that is the boundary the next set of controls crosses. AUTOMATIC1111’s common pipeline makes that comparison possible because the change can be traced to the stage where new information enters.