= Reproducible product visuals with AI image generators
Text-to-image models are now good enough that producing a single attractive product shot is no longer the bottleneck. The bottleneck is reproducibility: getting the same image back next month, and being able to show a reviewer how the accepted version was produced.
This article describes a small pipeline for AI-generated product imagery, the artefacts it keeps, and the failure modes that appear when it does not.
\b[The reproducibility problem]
A generator maps a prompt and optional reference images to an output. Several inputs sit outside the operator's control. The model behind an API can be updated without notice, sampling is stochastic, and a prompt retyped by hand from memory will not be byte-identical to the original. Any one of these is enough to make a previously approved image impossible to reproduce.
The practical consequence is that an approval has to be attached to something stable. In a physical studio that is the negative plus the lighting setup; in a generated pipeline it is the prompt plus the reference set.
\b[Split every accepted image into three artefacts]
The minimum bookkeeping that survives a model upgrade is three separate items per accepted output:
* the reference photo, sketch, or crop that anchors the object,
* the prompt, stored verbatim, including any negative phrasing,
* the output itself, stored next to the prompt that produced it.
Keeping the prompt as a text file under version control rather than as a string inside a chat log is what makes the rest of the pipeline possible. A prompt is source code: it should be diffable, and a change to it should be attributable to a decision rather than to a retyped approximation.
\b[Anchor the object with a reference image]
Pure text-to-image is the wrong tool when the object itself must stay faithful. A generator that has only seen a description will invent details: a different bezel, a different label, a different number of buttons.
Image conditioning removes most of that drift. For this step the workflow uses https://seedream50.pro/[Seedream 5.0 Pro], which supports text-to-image, image-to-image, sketch input and multi-reference batches. The multi-reference mode is the useful part for catalogue work: several views of the same object can be supplied together so that one detail stays consistent while the background changes.
\b[Prompt bookkeeping in practice]
A prompt stored as one long line becomes unmaintainable after the third revision. Splitting it into labelled blocks helps:
* subject and material,
* camera angle and framing,
* lighting,
* background,
* explicit exclusions.
Explicit exclusions matter more than they look. Most corrections that come back from review are "remove this", not "add that", and a negative clause is cheaper to keep forever than a second generation pass repeated every time. The same applies to framing: a fixed aspect ratio and subject position written into the prompt block keeps a catalogue grid aligned without a second compositing step.
\b[Failure modes to check before publishing]
Three classes of defect appear often enough to be worth a fixed check:
* invented detail, such as text on a label, a logo, or a port that does not exist on the real object;
* hands and reflective surfaces, which are still where generators fail most visibly;
* edge artefacts where a mask meets the background.
None of these are visible in a thumbnail, and a wrong label that ships costs more than the generation that produced it, so a review pass at full resolution is not optional. It is also worth re-checking the same output after any model update, because a prompt that behaved on one version is not guaranteed to behave on the next. Storing the model identifier alongside the prompt turns that re-check from a guess into a diff.
\b[A short checklist]
* Reference stored: yes or no.
* Prompt stored verbatim, under version control.
* Output stored next to the prompt that produced it.
* Exclusions listed explicitly rather than left implicit.
* Full-resolution review performed before publishing.
* Model version recorded at generation time.
\b[In closing]
Reproducibility in AI product imagery is bookkeeping, not modelling. Storing the reference, the prompt and the output together turns a stochastic generator into a process that can be reviewed, repeated and audited. The generator will keep changing; the artefacts are what let the work survive that change.
The same structure scales past a single operator: once the prompt is a file rather than a habit, a second person can reproduce an image without asking the first one what they typed.
Back to article page
