AI Pet Try-On: The Hard Part Is Keeping Things Unchanged

Imagine reviewing an AI-generated product photo: a beagle in a striped sweater, soft studio light, convincing knitted texture.

Then you open the reference images. The dog's white facial marking has changed. The sweater has an extra stripe. One sleeve ends somewhere inside a front leg.

Would you mark the generation as successful?

For a pet clothing shop, those details determine whether the image represents the animal and the item they supplied. For a developer, they expose a useful question: what does “correct” mean when the output is an image?

Pet try-on is a good place to make that question concrete. The requested edit is small—put this garment on this pet—but the result has several independent requirements.

Define what must stay the same

A useful brief starts by separating the requested change from the properties it must preserve.

Area	What to check against the references
Pet identity	Face shape, visible fur markings, ears, body proportions, and pose
Product identity	Color, pattern, neckline, fastenings, and garment construction
Anatomy and contact	Plausible limbs, garment openings, and boundaries between fur and fabric
Composition	The pet and the relevant product details remain visible

These checks need interpretation. A sweater will cover fur that was visible in the input. Fabric will bend around the body, so stripes should not retain the exact pixel geometry of a flat-lay photograph.

The useful distinction is between a change required by wearing the item and an unrelated change to the animal or product. A curved stripe can be reasonable. Inventing a zipper is a different matter.

That gives a reviewer something more specific to evaluate than whether the image looks polished.

Give each reference a clear job

For the simplest version of the task, there are two inputs:

• The product image defines the garment to reproduce.
• The pet image defines the animal to preserve.

In our project, Tufty, the built-in pet dress-up template uses both. Its prompt asks for the pet's breed, coat color, body shape, and pose to remain unchanged, while the garment's cut, color, pattern, and details should match the product reference.

Those are instructions to the model. They still need to be checked in the result.

A simplified English version of that brief looks like this:

Reference 1: the garment to reproduce.
Reference 2: the pet that will wear it.

Put the garment from reference 1 on the pet from reference 2.
Preserve the pet's visible identity, body proportions, and pose.
Preserve the garment's color, pattern, neckline, and construction.
Adapt the fabric naturally around the body.
Keep the complete pet visible against a simple studio background.

The request builder has to preserve that ordering too. If the prompt describes the first image as the product, the payload must put the product there. Keeping the prompt and reference ordering together makes this relationship easier to inspect.

For a batch, explicit product–pet pairs also make the intended outputs clear. Two garments and three pets produce six pairings if every combination is wanted. Each result should remain associated with its own references so the reviewer can compare the correct images.

Keep a beautiful result from hiding a failed requirement

Consider a candidate that scores highly for lighting and texture but changes the garment's neckline. Averaging those qualities into one score could make the candidate look acceptable.

For product representation, I would treat identity, garment fidelity, anatomy, and framing as required checks. Styling preferences can help rank the candidates that pass.

Here is a small TypeScript sketch for recording a human review. This is a proposed evaluation pattern, not an existing automatic scoring feature:

type Verdict = "pass" | "fail" | "unclear";

type Review = {
  petIdentity: Verdict;
  productFidelity: Verdict;
  anatomy: Verdict;
  framing: Verdict;
};

function passesReview(review: Review): boolean {
  return Object.values(review).every((verdict) => verdict === "pass");
}

const candidate: Review = {
  petIdentity: "pass",
  productFidelity: "fail", // The neckline differs from the reference.
  anatomy: "pass",
  framing: "pass",
};

passesReview(candidate); // false

The unclear state matters. If a fastening is hidden in both the source photograph and the generated result, the reviewer may have insufficient evidence to approve it. Recording uncertainty preserves that distinction.

The function only applies the decision rule. A person still has to examine the images and supply the verdicts.

Make the next experiment explain something

When a candidate fails, write down the specific difference before generating another one.

If the garment reference contains overlapping items, try a clearer image of the same garment. If the fur–fabric boundary is difficult to judge, try a pet reference where that body area is unobstructed. Keep the remaining settings fixed while changing that one input.

A small evaluation set can deliberately include different challenges: a plain garment, a repeating pattern, long fur, and a less straightforward pose. Keep the inputs, output, prompt version, and review together. That lets you revisit the same cases when the workflow changes.

Two useful measurements are the fraction of outputs that pass review and the total time needed to obtain an accepted image, including retries and inspection. Record the number of cases alongside any percentage; a handful of attractive examples cannot establish general reliability.

Even a candidate that passes visual review does not establish physical fit. A generated photograph cannot confirm measurements, comfort, or how the garment behaves on a moving animal.

The engineering task is to make the requested change explicit, preserve the evidence needed to judge it, and give failures a name. That makes the next iteration easier to reason about.

If you build image-editing workflows, which requirement would you turn into a mandatory check first?

This article was drafted with AI assistance. The cover is AI-generated concept artwork, not a measured product result.