Why virtual clothing try-on diverges from reality
Fit discrepancies are born not in the model, but in the input data. Mixed lighting in the shoot distorts tone and microtexture: knitwear looks denser than it is, denim loses its texture.
The mannequin’s pose and the lack of scale in the frame add a second error — real proportions cannot be reconstructed from such a shot, and the algorithm fills them in using average values.
Then the error accumulates. Fabric without captured characteristics — stretch, drape, thickness — falls smoothly on the virtual figure but fits with folds in different places on a person.
The buyer sees one thing and gets another: size-related returns account for a noticeably larger share of failures than any other reason.
Returns are also logistics: shipping there and back, loss of salable condition, support time to resolve size-chart complaints. But worse is undermined trust in the product page — one inaccurate image, and the buyer no longer believes the description or the measurements.
This is addressed in catalog preparation: product shoot quality is set before images reach the model — even neutral lighting, color reproduction control, a reference height in the frame, fixed angles and poses.
Fabric properties are captured separately, and they enter the product page as a measurable characteristic, not as a wish. Then the fit on the virtual figure matches reality, and size-related returns stop being the norm. We break down how this is addressed at each step.
What changes after implementation: measurable effects
The effect of virtual try-on is visible in store analytics, not in reviews about the wow effect.
Therefore, before launch, we record a baseline across five metrics on the same product set and compare it with the same indicators 4-6 weeks after enabling — otherwise the numbers are influenced by seasonality and advertising, not by try-on. We look at each point.
- Fit-related return rate. The reason “didn’t fit by size” leaves the top 3: the buyer sees the fit on their own silhouette and chooses a size deliberately. We count it separately from quality and defect returns — otherwise the effect is diluted.
- Product page conversion. It grows because the path “size → fit → add to cart” is completed on the product page, without going to size charts and reviews. The control group is product pages without try-on.
- Product preparation time. One shoot on a pattern covers the entire size range: new colors and sizes are published without rephotographing. We store the model and textures in the open Khronos format so they can be reused in other channels without vendor lock-in.
- Engagement depth. Try-on adds 1-2 minutes and 2-3 size switches per visit — this is visible in page events. The metric shows that the product is being studied, not skimmed.
- Eliminated class of failures. Previously, incomplete size charts produced “wrong size” directly on the product page. After auto-validation of the size chart and model at publication, this class of failures disappears — support stops handling repetitive tickets.
Generation modes: comparison of approaches and limitations
The generation mode is chosen not by “image quality” in general, but by what is already available at the input and how accurate the fit must be.
One catalog can go through mannequin photography, photo-based generation, or a pre-built 3D clothing model — lead time and realism class will differ.
| Option | When it fits | Limitations |
|---|---|---|
| Mannequin photography | Even catalog, uniform lighting and angles, predictable geometry needed | The mannequin averages the figure, fit on non-standard body types is not readable, when the cut changes the shoot is repeated |
| Photo-based generation | Product is already photographed, fast coverage of the item pool is needed | Strict requirements for source images: clean background, even lighting, angle; print and small folds may “float,” frame selection is needed |
| 3D clothing model | Complex cut, jeans, outerwear, fit accuracy is important | Patterns or sample digitization are needed, preparation per item takes longer and requires manual geometry checking |
What determines the choice
Processing speed differs by an order of magnitude: photo-based generation produces the first images in minutes and processes the item pool in batches, mannequin photography is limited by the studio schedule, and the 3D model is limited by digital pattern preparation.
In practice, a hybrid is more common: base items are covered by photo-based generation, while flagship and fit-problematic items are covered by the 3D model. Requirements for source images are fixed before the start — whether additional shooting is needed depends on this.
Try-on implementation stages: from audit to handover
The workflow is the same for a catalog of a couple hundred product pages and for a marketplace with tens of thousands of SKUs: first we analyze what makes sense to try on, then we build the solution design, and only then do we write code.
Each stage closes with a verifiable artifact — otherwise try-on turns into endless “by eye” refinements.
- Catalog audit. We review product page markup, shoot quality, angle repeatability, and the presence of size charts. The output is a list of categories where try-on will produce a correct result and those where additional shooting is needed.
- Solution design. We determine how the human model is built from a photo, how clothing is transferred onto the silhouette, where source assets are stored, and how the block is embedded into the product page and cart. We separately fix behavior for an uncertain result: try-on honestly reports low accuracy instead of a pretty but incorrect image.
- Prototype. We assemble try-on on two or three categories and test the design on live data: how fabric behaves in different poses, whether the result is stable on non-standard figures.
- Catalog setup. We run the entire catalog, refine rules for problem categories, and configure intermediate storage of ready results — a product page with try-on opens as fast as a regular one.
- Control sample. We collect a sample by body types, heights, poses, and complex fabrics, compare it with photos of real try-on, and calculate the share of matching fits.
- Result acceptance. The client checks metrics on their own sample, try-on performance on mobile, and the absence of false positives. Discrepancies are resolved and closed before handover.
- Process handover. We provide documentation, access, and regulations for replenishing the catalog with new categories, and train the client’s team — after that, the catalog is updated without our involvement.
Configurations, access, and project documentation
We consider the project delivered not when try-on works on a test catalog, but when your team has the full set: settings, designs, policies, and regulations.
Then launching a new collection, changing the shoot contractor, or onboarding a new employee does not require us as an intermediary.
- Solution design — composition of the try-on service components, data flows between the catalog, model storage, and storefront, failure points, and how each is isolated.
- Configuration for your assortment — set of categories, fit rules for different fabric types, size charts, size suggestion thresholds.
- Access policy — roles (catalog administrator, shoot operator, analyst, support), what each can see and change, action log, and record retention periods.
- Team instructions — how to add a product, replace a model, update the size chart, and roll back an erroneous change without contacting us.
- Shooting regulations — requirements for product photos and videos, lighting, angles, allowed backgrounds, and a batch acceptance checklist before upload.
- Content moderation policy — what enters the try-on storefront, how incorrect frames are filtered out, and who makes the decision in disputed cases.
- Support regulations — update frequency, incident owner, response time, procedure for planned work and dependency updates.
We hand over the set in your environment: descriptions of integrations and environments, secrets in secure storage, change history, and recorded handover — so support does not depend on one person.
Case: how catalog operations changed after implementation
Starting point
A retail chain’s catalog — about 12 thousand models, and each product page was prepared through a classic pipeline: studio, photographer, 6–8 angles on a live model, 5–7 days per batch.
Part of the assortment entered the catalog without try-on for different body types at all, and the clothing return rate held at 28%: the buyer did not understand the fit, ordered two or three adjacent sizes, and returned the extras. This was the main loss item — not delivery, but size uncertainty.
What we did
We built virtual try-on as a separate block inside the product page: silhouette segmentation using Segment Anything, body map construction from one customer photo, texture transfer, and fitting by measurements — bust, waist, hips, height, sleeve length.
The model is shown on the user with text fit notes: “loose in the shoulders,” “tight in the waist,” “length covers the hips.” Next to it is a recommendation of an adjacent size with rationale, not an abstract “M will suit you.”
What changed
Product page preparation time dropped from 5–7 days to 4–6 hours: a batch of 200 models goes to the catalog in one shift, and studio shoots no longer hold up the collection release.
The return rate due to “wrong size” fell from 28% to 11% over two quarters of observation — the effect holds because the buyer changes their decision before ordering, not after delivery.
Behavior on the product page also shifted: the share who opened try-on is 41%, their engagement depth is 2.3 times higher, and two thirds add the product to cart directly from the try-on block.
Returns decreased most on the “mid-range” sizes — M and L, where the buyer previously chose at random between adjacent sizes.
How photo-based generation differs from 3D scanning
Photo-based generation reconstructs the figure from a set of flat projections; a 3D scan captures real body geometry — hence the different requirements for source images.
For photos, several full-length frames in even diffused light, on a plain background, with a fixed camera position are enough: wide-angle optics and a top-down angle create distortions that the model then honestly transfers into the fit.
Scanning requires a studio, calibrated equipment, and an operator, but shooting can be done without regard to lighting and background.
Fit accuracy depends on the clothing class. The photo model confidently handles loose silhouettes, knitwear, and outerwear; on dense fabrics and rigid patterns, circumference error is noticeable, and scanning wins there.
The selection criterion is simple: if size-related returns in the category are already high, the difference will show in try-on; if not, the photo approach is enough.
Processing speed is the second fundamental difference. The photo model is assembled when the customer uploads and is available immediately; scanning is recording, cleanup, and mesh preparation, a separate stage before the first try-on.
Model reuse works in both cases: an avatar built once is inserted across the entire catalog, while fabric and patterns change on the product side, not the customer side. Re-shooting is needed only for a significant change in figure.
Therefore preparation cost is calculated by scope of work, not by technology: the photo pipeline is shooting regulations and frame validation, while 3D is studio, equipment, and operator.
For a mass catalog, a hybrid is more practical: photos for the base line, scanning for premium rigid items.
Complex cases: fabrics, lighting, and body types
Difficulties begin where the physics of the material changes, not the cut. Satin, leather, sequins, and membranes produce directional highlights — if they are not separated from body shape, the item looks like a pasted-on image.
Transparent materials and layered clothing add a second contour: a dress reads under a coat, and both layers must move consistently.
Light shades and large sizes break in other places. On white and milky, the silhouette boundary is lost — without it, you cannot tell where the fabric clings and where it hangs.
On large sizes, the fit depends on volume distribution, so stretching a single template creates distortions in the shoulders, chest, and hips. We handle this with separate sets of rules and materials, not one universal model.
How do you work with shiny fabrics?
We build a separate reflection map and suppress highlights where they interfere with reading the shape. Sequins and foil are treated as a non-uniform surface — otherwise the result sparkles and the item looks artificial.
What about transparent materials and layered clothing?
Each layer is computed separately, and the layering order is set manually: a transparent top does not erase the bottom. Chiffon over a dress preserves both textures instead of turning into a blurred spot.
Why do light shades and large sizes require refinement?
Light items lack contrast — we add a silhouette boundary and a soft shadow along the contour. For large sizes, we rebuild the fit mesh to real proportions so the sleeve and armhole do not float during movement.
Let’s discuss your task and come back with a plan
Analyzing the task takes one conversation, but without it the estimate turns into guesswork.
To come back with a work plan and timelines, we need to understand the clothing category, catalog volume, and where try-on will live: on the product page, in the app, or in a dialogue with a consultant. Below is what we will need from your side and in what form the result will come.
- Scenario and categories. Send 2-3 products where virtual clothing try-on is needed first: knitwear, outerwear, and footwear require different fit accuracy and different source data.
- Data requirements. We need patterns or 3D models for a sample of SKUs, a size chart, and reference fit photos. If models are absent, we will estimate their preparation separately.
- Customer data. Where customer photos are stored, how long they are retained, and what consents we obtain — we fix this before the start so we do not have to redo the entire setup later.
- Stage order. Task analysis → try-on on a limited product sample → fit verification with a technologist → rollout to the catalog → handover to support.
- Scope of work. Model preparation, fit setup, catalog integration, try-on interface, and quality control of the result for each product batch.
- Handover to support. Update regulations when the collection changes, environment documentation, an owner on your side, and our escalation points.
- Work plan. We come with stages, dependencies, and acceptance points — each item shows what counts as a completed result.
Describe the task in free form — we will come back with an estimate, a work plan, and a list of questions that need to be closed before the start.
