XGen

XGen was an advertising and marketing content-generation platform. The product problem was to turn a creative brief into controllable image and video variations: a useful visual direction, an approved starting frame, a coherent motion sequence and assets ready for review and delivery.

The technical work used ComfyUI workflows and reusable model components. The recovered material includes image-generation graphs, prompt libraries, design work and video samples. This case study connects that evidence to a concrete text-to-image → image-to-video pipeline using Nano Banana, ComfyUI and Wan 2.1.

The new reference implementation is documented separately from the historical artifacts. Its configuration and JSON examples are inspectable, but they are not presented as a recovered production deployment or a newly measured GPU benchmark.

What the retained samples reveal

A metadata inspection covered 495 PNG files inside the retained sample archives. 240 contained both ComfyUI prompt and workflow metadata before the image-data chunk. That gave us a useful record of the experimentation without publishing the original media or private prompts.

The graphs reference SDXL checkpoints, FLUX models, LoRA loaders, wildcard composition, face and hand detailers, upscalers and comparison nodes. Some later graphs explicitly reference Wan 2.2. A shared wan_2.1_vae.safetensors filename does not make those graphs Wan 2.1 runs.

A graph reference establishes that a component was configured in the retained workflow. It does not establish that every node affected every output. We also did not recover model-file hashes, an exact Civitai version for every filename, or historical Runpod allocation records. The series explains how to preserve those identities in future runs.

The product workflow

The central product decision is to approve the still image before spending on motion. A wrong product silhouette or poor composition becomes more expensive to correct once a video has been generated.

The reference separates two image routes. Nano Banana provides a managed image-generation/editing path. A self-hosted SDXL/FLUX route retains access to compatible local LoRAs. Those adapters are not interchangeable: a Civitai SDXL LoRA cannot simply be attached to Nano Banana or Wan.

Image generation: turn the brief into an approved keyframe

A structured creative brief records the subject, product identity, camera, lighting, composition, required empty space and prohibited changes. The public example uses an invented reusable-bottle campaign, avoiding client assets and personal likenesses.

The Nano Banana example explicitly selects gemini-2.5-flash-image, the original model associated with that name. It is a reference integration using a named model, rather than an ambiguous alias for whatever image model is current. Its output is reviewed, saved with provenance and deterministically prepared for the video input. Google image-generation documentation

The self-hosted path has a different reproducibility contract: checkpoint hash, model family, LoRA versions and strengths, seed, dimensions, sampler, scheduler and custom-node versions. The recovered prompt library’s separation of camera, lighting, subject and background makes sense here, but the final rendered prompt must also be saved.

Video generation: condition on the approved image

The reference ComfyUI graph uses Wan 2.1’s 14B I2V 480P checkpoint, a UMT5 text encoder, CLIP Vision and the Wan VAE. It generates 81 frames at 832 × 480, with 16 fps chosen for the encoded output. That is 5.0625 seconds of encoded frames; the interval from the first to last frame timestamp is five seconds.

The graph includes image loading, vision encoding, text conditioning, image-to-video latent construction, sampling, VAE decoding and frame saving. A separate encoding stage turns the recorded frame sequence into the review file. It does not pretend that a generic SDXL ControlNet can be inserted into the Wan graph. ComfyUI Wan examples

The download includes the complete API-format graph and a matching motion-prompt example. A deployment must validate it against the installed ComfyUI node schemas and run a real smoke generation before accepting production work.

GPU resources and operational design

The series provides explicit Runpod planning profiles: a 24 GB RTX 4090 development lane, a 48 GB L40S worker lane and an 80 GB A100 validation lane, with corresponding CPU, host-memory and disk budgets. They are proposed allocations, because the retained project materials do not establish which historical Pod was rented.

The key operational split is between model execution and everything around it. GPU workers run admitted generation jobs; a durable queue records their ownership and outcome. CPU workers handle encoding and packaging. Model storage is cached persistently, while accepted outputs and run manifests are copied to durable object storage.

No queue should retry a costly generation indefinitely. Every attempt needs a budget, a lease, an immutable input image and a unique artifact prefix. A timeout after generation should trigger artifact reconciliation before another GPU run.

Evaluation for advertising

The acceptance question is whether the asset can be used for the campaign. Image review checks product geometry, composition, color and reference fidelity. Video review adds temporal consistency, motion quality, product deformation and flicker. Text, prices and logos can be composited in a controlled finishing stage when exact reproduction matters.

Generation speed is only one operating metric. We also need cost per accepted asset, retries per approval, review time and the fraction rejected for brand errors. A fast workflow that repeatedly changes the product can be commercially worse than a slower one with predictable output.

My contribution

As architect and lead, my contribution connected the advertising workflow to model and pipeline choices: reusable prompt composition, configurable image-generation components, image-to-video experimentation and the product controls needed to turn generation into reviewable creative work.

The accompanying articles make the work inspectable through recovered component names, explicit compatibility boundaries and a reference implementation that can be independently checked. They also develop the operating model: admission control, bounded retries, persistent model caches and cost per accepted asset.

Explore and reproduce the pipeline

• Read the six-part XGen engineering series.
• Download the workflow, prompts, worker profiles and validation tools.
• Inspect the Wan 2.1 API graph.
• Inspect the image prompt request and video prompt specification.

The examples contain no client media, API keys or model weights. Offline structural checks are reported in the kit; actual model quality, generation time and memory consumption remain deployment measurements.