Personalizing Image Generation: DreamBooth, LoRA and Textual Inversion

text-to-image-diffusion-models designed a system that can generate a photorealistic image of more or less anything a user can describe in words — except the one thing users of a headshot app actually want: a photo of themselves, rendered in a studio-lit, LinkedIn-ready style. A model trained on hundreds of millions of image-caption pairs has learned what "a professional headshot" looks like in general, and it has never seen your specific face. That's not a data-quality problem the earlier subject's pipeline can fix — no amount of better captioning or CLIP-score filtering teaches a model a person it was never shown. It's a new problem: personalization, and it's the most product-shaped subject in this track for a reason — "design an AI headshots product" is a real, frequently asked interview prompt, and it forces every design decision (which tuning method, how much data, how it's evaluated, how it's served) to answer to a concrete business constraint, not an abstract quality bar.

This subject assumes you've internalized text-to-image-diffusion-models's vocabulary and doesn't re-teach it: diffusion training (the noise-prediction objective, conditioning on a caption embedding and timestep), CLIP and CLIPScore, and the U-Net's cross-attention mechanism all get referenced by name here, not re-derived. What's new is everything about taking that pretrained model and teaching it one specific subject, cheaply enough and reliably enough to ship as a product with a same-day turnaround.

Clarifying Requirements

The framework is the same loop this track always uses, but the numbers this time are shaped by a concrete product, not a research benchmark:

• Input: a small set of user-uploaded photos of one subject — typically 10 to 20 images, since that's roughly what a real user is willing to upload and roughly what the tuning methods below need to work with.
• Output: a handful of new, photorealistic images of that same subject in a fixed style — professional headshots, not arbitrary user-typed scenes. This scoping decision matters: it means the product does not need to support free-form prompts at inference time, which turns out to simplify both the sampling design and the safety story later in this subject.
• Turnaround: a same-day SLA is a reasonable target for a consumer product — minutes to low tens of minutes of processing time per user is acceptable; this is the number that ends up justifying the tuning-method choice below, so pin it down explicitly before comparing methods.
• Identity fidelity is the product. Unlike subject 2, where "does this look photorealistic" and "does this match the prompt" were the two quality axes, here there's a third, dominant axis: does the output actually look like this specific person. A beautifully lit, photorealistic headshot of someone who doesn't resemble the user is a failed generation, full stop — this reframes the entire evaluation section later.
• Scale: potentially millions of users, each needing their own personalized model or adapter — a very different scaling shape from subject 2's one shared model serving everyone. Whatever tuning method gets chosen has to be repeated per user, so its per-user cost (training time, storage) is a first-class product-economics question, not an implementation detail.