How an AI model learns your product from a few dozen photographs, and why photographers should care too.

A LoRA is a small file that teaches an AI image model one specific thing. Your product. Your lighting. The way you shoot. It takes a few dozen photographs to make, and once it exists it can produce that thing on demand for as long as anyone has a copy.

If you’re on the brand side, it’s how an AI model learns to reproduce your product reliably instead of approximating it. If you’re a photographer, it’s trained on your frames, and it’s the best pitching tool you’ve been handed in a long time. Five minute read on how these tools work covers both.

Start with the tools themselves, because there are two kinds.

The first kind you’ve used. Midjourney, ChatGPT’s image generator, Firefly, Runway. You type, you upload, something comes back. The model runs on the company’s servers. Your images go to them, the work happens there, and what happens to your images afterward is whatever their terms of service say it is. This is convenient, and for most of the world it’s the whole story. It’s also where most photographers first met these tools, for previz and for pitching a direction. Previz is probably where they fit best in a photographer’s business. More on that in a minute.

The second kind is what a post studio runs. Stable Diffusion, Flux, and a handful of others are released as open weights, meaning the model itself is a file you can download and run on your own machines. Black Forest Labs, which makes Flux, describes the offer plainly on its licensing page: “Fine-tune on your data, self-host on your infrastructure.” You need serious graphics hardware and someone who knows how to run it, and for commercial work you pay for a licence. What you get in return is that nothing leaves the building. Your images are never sent anywhere. Nobody’s terms of service apply to them because nobody else ever has them.

There’s a second thing about the big publicly available models that surprises people: using one doesn’t teach it anything. Generating ten thousand images of a product doesn’t make the model know the product. Learning only happens in a separate, deliberate training step. Which is where this gets interesting.

An image model has looked at billions of pictures and stored what it learned as a very large set of numbers. It knows what a watch is. It knows what brushed steel does under a softbox. It does not know your watch. It has never seen the case shape you spent eighteen months on, and if you ask for it you’ll get a plausible watch that isn’t yours.

You could fix that by retraining the whole model on your product. Nobody does. The model is tens of gigabytes. Retraining it takes days on expensive hardware. And you’d end up with a full copy of the model for every client, which stops being manageable the moment you have a second client.

LoRA is the workaround. The idea comes from a 2021 Microsoft paper called “Low-Rank Adaptation,” written for language models and borrowed by the image world within a year.

Leave the base model exactly as it is. Frozen. Alongside a few of its layers, add a small set of new numbers and train only those. The new numbers learn the difference between what the model already believes a watch looks like and what your watch actually looks like. Load them and the output bends toward your product. Unload them and the model is generic again.

The closest thing in post is a show LUT. The colorist’s experience is the base model. The LUT is a small file that steers every shot toward one specific look without retraining the colorist. The analogy isn’t perfect, since a LoRA is learned rather than authored, but the shape is right. Small, specific, sits on top, switches on and off, stacks with others.

Small is the point. A base model is tens of gigabytes. A LoRA is usually a few hundred megabytes. It fits on a thumb drive.

Here’s what training one takes.

A set of images. A few dozen is typical for a single product, more if you need it across angles and materials. For a photographer’s look, it’s a few dozen frames from the portfolio. A caption for each one. A few hours on a capable GPU. That’s the recipe.

Look at the first ingredient again. To train a model on an unreleased product, you hand over images of the unreleased product. There’s no version of this where you don’t. For the brand, the training set is exactly what the NDA exists to protect. For the photographer, it’s the portfolio. Either way it has to go wherever the training happens.

And when training is done, the output is a few-hundred-megabyte file that can generate the product on demand, indefinitely. For a brand, that’s a machine for producing the thing you’re embargoed from showing anyone.

For a photographer, the same mechanism points the other way. Train a LoRA on your own portfolio and you can show a client their concept in your style. Not a mood board of other people’s pictures. Frames that look like you shot them. That’s a pitch, that helps win the job; then you go shoot the job. The previz should look like a sketch, not a final, for exactly the reason I wrote about in June. But it’s the first time a photographer has been able to previz stills in their own look, and the people doing it are winning more of the rooms they walk into.

One more thing about the training set: it comes up the moment there’s a person in the frame. A LoRA learns whatever you show it, which means you decide what it learns. If the product shots have talent in them, the faces can be cropped out, masked so only the product counts during training, or handled in the captions so the model is told to learn the bottle and not the person holding it. A photographer training on a portfolio does the same in reverse: keep the light, leave out the faces. None of this is automatic. Someone has to make that call before training starts. A recognizable face that goes into a training set can come back out of the model.

Which leaves the practical question: where does all of this actually happen? Where do the photographs go for training, and where does the finished file live afterward?

There are three answers.

The first is consumer and community tooling, the hosted platforms and cloud trainers most people met first. The terms vary and some are frank about it. Midjourney’s Section 4 opens with “By default, Your Content is publicly viewable and remixable” and grants a perpetual, irrevocable licence to inputs and outputs. Midjourney doesn’t train LoRAs, but that’s the standard of care much of the consumer tier was built to, and neither a brand’s product shots nor a photographer’s portfolio belongs anywhere near it.

The second is vendor cloud under enterprise terms. OpenAI’s API is the reference point for what decent terms look like: no training on your inputs by default, retention capped at 30 days for abuse review, zero retention on request for qualifying customers. Adobe indemnifies qualifying customers and says it trains only on content it has rights to, with the caveat that third-party models inside Adobe’s own apps run under different terms (and this is a common issue with other AI platforms that plug in various AI engines as well). This tier can work. It requires reading the documents, confirming which tier you’re actually on, and getting retention and deletion in writing.

The third is the open-weights route from the top of this piece: training on hardware you control, on a network the training set never leaves.

Two things come out of a training run: the photographs you put in, now sitting wherever the training happened, and the file that came out. My opinion is that both should be handled with the same chain of custody as the raw camera files. A file that can regenerate the product deserves at least the care given to the files that captured it once.

What good looks like isn’t complicated. The training set never leaves a private network. Training runs on hardware the studio controls, or under written terms that say no training and specify deletion. The finished LoRA is stored, access-controlled, logged, and either handed to the client or destroyed at wrap, in writing. No consumer tool anywhere in the chain. And someone can answer, on paper, which model, which tier, what retention.

Photographers have one more line to add. A LoRA trained on your portfolio is a pitching tool and it’s yours. Train it somewhere it stays yours, and don’t hand it over with the treatment. If a client or agency instead asks to train on your frames for their own production, that’s a different thing. It’s a new use of your work, one most image licenses were written before, and it belongs in the license like any other use. I’m not a lawyer and this isn’t legal advice, but it’s a conversation to have before the files go over, not after.

For what it’s worth, that list is the standard we ended up holding ourselves to, and it’s why our LoRA training runs on our own hardware behind a private network rather than through anyone’s cloud. It wasn’t a philosophy. The consumer terms failed the list outright and the enterprise terms passed only after more paperwork than a campaign timeline allows. The rest of our operation (scheduling, approvals, routing client correspondence) runs through ordinary commercial APIs, because a calendar invite is not a trade secret.

That’s a description...however, not a recommendation. Most studios shouldn’t build infrastructure. But every brand can hold whoever they hire to the list, and every photographer can hold whoever’s asking for their frames to it.

Brands: if a model was trained on your product this year, by anyone, do you know where the training set is right now? Photographers: have you tried pitching with previz in your own look yet, and did it change how the room went? I’d like to hear both.