MirrorMargin

• 

  The fixed person and upper-body garment inputs used for both YouCam VTO runs.

• 

  MirrorMargin compares both YouCam outputs and reports an 87/100 edge-agreement score.

Inspiration

Virtual try-on is good at answering one question: “What might this look like?” The trouble starts when a polished image quietly suggests an answer to a different question: “Will this fit?” A generated preview cannot measure comfort, stretch, drape, or the gap between a body and a garment size chart.

MirrorMargin keeps those questions apart. Instead of treating one attractive render as proof, it runs the same try-on twice and shows whether the output is repeatable. Physical fit still goes to a measurement check.

What it does

A user supplies one front-facing person image and one upper-body garment image. MirrorMargin sends the identical pair through YouCam Apparel VTO V4 twice, places both results side by side, and calculates an edge-agreement score from 0 to 100.

The demo pair scored 87. Both renders clearly show the cream sweater, but the lower hem changes: one result folds upward while the other hangs straight. That is exactly the kind of uncertainty a single render would hide.

MirrorMargin then gives the shopper a practical next step. Chest, waist, hip, and garment-length fields sit beside the comparison so those values can be checked against the retailer’s chart. The interface never labels the score as fit confidence.

How we built it

The interface uses React, TypeScript, and Vite. The controlled server path registers the two source files with YouCam, uploads them to the signed URLs returned by the File API, and creates two cloth-v4 tasks with the same file IDs and upper_body category.

When both tasks finish, the server downloads the result images from an allowlisted YouCam asset host. Each image is resized to the same dimensions and converted to a grayscale edge map. The score is the percentage of edge responses that agree within a fixed tolerance.

The public deployment uses a replay of the real YouCam outputs. It cannot make anonymous API calls, expose the key, or consume the free unit balance. The live route remains in the repository for controlled testing and requires a server kill switch, a separate browser build flag, and a server-verified access token.

Challenges

The hardest product decision was refusing to turn image similarity into a fit prediction. A high score can make a result look authoritative, so the copy, layout, and measurement handoff all had to reinforce what the number does and does not mean.

We also had to protect a limited API allowance. A public live endpoint would let anyone spend the project’s units. Replay mode preserves a working public demo while the server integration remains reviewable and testable.

Finally, a plain pixel average gave the real pair 99/100 even though the hem difference was easy to see. Comparing edge responses brought that local structural change into the score and produced the final 87/100 result.

What we learned

Repeatability and accuracy are different. Running a generative workflow twice can reveal instability, but matching outputs can still be wrong about the physical world. The useful design move is not to hide that limit. It is to route the unanswered question to better evidence.

What's next

The next step is to test the signal against retailer-approved garment charts and return-reason data. A production version could set category-specific thresholds and explain which regions changed, while keeping measurements and return policies in charge of the purchase decision.

Built With

• node.js
• react
• sharp
• typescript
• virtual-try-on
• vite
• vitest
• youcam