DEMO & IMPLEMENTATION GUIDE
Your own jewelry try-on system.
This is an independently built demonstration of the shopping-to-camera experience you described: choose jewelry, permit camera access, see jewelry follow detected facial features, combine pieces, and save a look. The application uses Google's MediaPipe vision models. It does not call Mirrar, use Mirrar assets, or reproduce its proprietary technology.
Scope: real landmark inference and illustrative 3D jewelry rendering, with a labeled 2D fallback. This is a prototype for evaluating the interaction and fitting approach, not a claim of production parity with an established commercial try-on service.
1. Walk through the demo
- Open the studio on HTTPS or localhost. Select either of the two pieces in each category. The initial selection is Solstice hoops.
- Choose Enable camera and approve your browser's camera request. Audio is never requested. Camera frames remain on the device.
- Wait for the face and pose models to download. A loading failure presents a retryable message. Camera permission, missing-camera and camera-in-use errors have separate messages.
- Face the camera in even light. Keep your hair behind your ears. For necklaces, include both shoulders and the upper chest.
- Turn gently and move nearer or farther away. Jewelry anchors follow the detected face. Turn on Show tracking guides to see facial landmarks and labeled anchors.
- Choose a necklace, nose piece or headpiece to layer with the earrings. Remove any selected piece using its own Remove button in Your look, tap its selected product card again, or choose Remove all. One selection is retained per category. Change finish, scale or vertical placement independently for each category.
- Use Save your look to download a still image without tracking guides. This does not send a photo to a server. Turn off the camera when finished.
- If no camera is available, use the sample-model button. Choose among four portraits: one licensed photo and three AI-generated studio models. The app runs landmark detection on the selected still photo. This mode is explicitly labeled as a still photo, not a live simulation.
2. Tracking coverage: detected versus estimated
| Region | Demo implementation | Important limitation |
|---|---|---|
| Face | 478 landmarks from Face Landmarker, confidence thresholds and temporal smoothing. | One face only; poor light, blur and occlusion can interrupt detection. |
| Eyes | Detected eye contours and iris landmarks appear in guides. Eye corners establish the face's orientation. | No gaze measurement or eye-jewelry product is implemented. |
| Nose | Nostril-side anchors position a stud or ring. The same nostril stays selected during turns; far-side visibility is gated. | Does not identify a real piercing or reconstruct nasal cartilage. |
| Head | Eye geometry provides roll. Nose offset gives an approximate yaw cue. Forehead landmarks anchor headpieces. | Pitch is derived from the facial transformation matrix, and yaw/roll from landmark geometry. Full calibrated six-degree-of-freedom fitting remains unverified. |
| Ears | Face contour anchors, optionally blended with visible pose ear landmarks. | Estimated attachment points, not dedicated ear/lobe/piercing tracking. Hair occlusion is not segmented. |
| Neck | Chin plus detected shoulders estimate necklace center, scale and shoulder-line rotation. | No neck surface reconstruction. Necklace drape is approximate and hides when shoulder confidence is insufficient. |
The corrected visibility logic hides the far earring on the same screen side as the head turn, using landmark depth as a second cue and hysteresis to reduce flicker. An explicit face-oval cutout prevents earrings drawing onto the cheek. This is a conservative visibility heuristic and a 2D face mask, not full 3D depth or hair segmentation. A hand covering the jewelry or hair crossing an earring is not correctly rendered in front of it.
3. How the system works
Product selection → camera frame → local vision worker → normalized landmarks → smoothed anchors → jewelry overlay.
- Camera: the browser supplies video after permission. A mirrored display feels like a fitting-room mirror.
- Vision: a dedicated worker loads pinned MediaPipe Tasks Vision 0.10.21 and the Face Landmarker and Pose Landmarker Lite assets. GPU/WASM inference runs outside the UI thread, with a CPU compatibility fallback.
- Scheduling: only one frame is in flight. Face frames are requested at up to 30 per second with only one in flight; actual speed depends on the device. Pose is requested at most roughly every 160 ms when earrings or necklaces need it. Reported milliseconds are measured inference duration, not a promised frame rate.
- Geometry: the app maps normalized landmarks into the exact letterboxed video rectangle and mirrors positions consistently. Depth-corrected face width determines apparent scale; eye alignment determines roll. This does not establish millimeter-accurate fit.
- Smoothing: an adaptive One Euro filter reduces jitter while responding more quickly to deliberate movement. Missing faces clear filter history. Camera results older than 350 ms from capture time are hidden; stale shoulders expire.
- Rendering: Three.js loads eight local GLB files reconstructed from the supplied front references, with built-in geometry as a download-failure fallback. Metal and pearl materials use studio reflections; gemstones use bounded ray intersections through their actual convex facets. The 3D result is composited onto the video with a face mask for earrings. A labeled Canvas fallback is available when WebGL fails. Catalog thumbnails and the rotatable detail viewer now use the same 3D construction as try-on when WebGL is available. These assets are not physically measured digital twins of real inventory. The studio reflection environment is authored. Low-resolution frame luminance adjusts exposure and reflection orientation; it does not reconstruct the room lighting.
- Lifecycle: stop, page hide and tab hiding release camera tracks, terminate the worker and clear overlays. Loading and frame watchdogs avoid indefinite waiting.
- Saving: the video and overlay are composited locally into a PNG on request.
The core source is separated into collection rendering, tracking geometry, the vision worker, application state and interface styling. Three.js 0.180.0 is bundled locally under its MIT license. No backend, account system, analytics, product database or checkout is required for this demonstration.
4. Turning this into a professional product
The next phase should focus on fitting and asset quality before expanding the storefront. A convincing shopper experience depends on accurate attachment points, correct real-world scale and believable occlusion as much as on landmark detection.
| Workstream | Production deliverable | Acceptance evidence |
|---|---|---|
| Product assets | Measured GLB/glTF models with correct metal and gemstone materials, paired earring origins, attachment metadata and optimized variants. | Jeweler-approved comparison against the physical product, dimensions and photographs. |
| 3D renderer | WebGL rendering, camera projection, depth-aware face occluder, lighting estimation and stable head transforms. | Accurate orientation during controlled yaw, pitch and roll sequences. |
| Ear fitting | Dedicated ear/lobe landmarks or a custom model, with piercing calibration and confidence gating. | Attachment error measured on annotated, consented test footage. |
| Neck fitting | Neck/upper-body geometry and necklace-specific drape constraints. | Fits across collarbone shapes, necklace lengths and shoulder poses. |
| Occlusion | Hair, face and hand segmentation combined with depth ordering. | Earrings disappear correctly behind hair and hands; far-side objects remain hidden. |
| Commerce | Real SKU and variant mapping, approved asset delivery, catalog management and host-store cart handoff. | Selected variant and displayed asset match, with correct store navigation. |
| Device quality | Adaptive model/render quality, cross-browser fallbacks and measured performance budgets. | Test results on target Android, iPhone, tablet and desktop hardware. |
5. Product asset contract
For each real product, record a stable product ID, category, variant ID, model URL, dimensions in millimeters, attachment origin, orientation, scale convention, left/right pairing, supported finishes and thumbnail. Store approved fitting adjustments per asset instead of embedding catalog-specific values throughout the tracking code.
For a 2D pilot, transparent cutouts can replace the parametric artwork, but they still flatten during rotation. Production 3D assets should preserve consistent units, have geometry centered around the attachment point, and include optimized textures. Transparent or refractive gemstones require careful rendering and device-budget decisions.
Start with a small representative set: a stud, a hoop, a long drop earring, a short pendant and a collar necklace. Approve these against real products before digitizing a large collection.
6. Integrating with your own website
The store's product page should open the fitting room with its product and variant selected. For an embedded experience, configure the iframe's camera permission and the host's Permissions Policy. Camera access requires a secure context and user permission. Do not assume that a camera works inside every in-app browser.
Keep commerce data separate from the tracking layer. The fitting room should accept a validated product selection and return the chosen product/variant to the storefront. Any cross-window messages must validate their origin and payload. A customer can then continue using the store's existing cart and checkout.
The Hostinger export contains no account restriction. Whoever can visit your deployed domain can open this static demo. The earlier Sites publication has its own access policy and is independent of the ZIP. A commercial catalog and checkout remain separate work. Local photo downloads are the only persistence in this demo; selections are not saved between visits.
7. Testing and release gates
- Tracking: compare anchor error and jitter on annotated footage, test frontal and rotated poses, and verify recovery when the face leaves the frame.
- Scale: do not advertise exact fit without a validated calibration method. A single RGB camera does not automatically provide true millimeter measurements.
- Occlusion: test long hair, hair across one ear, scarves, hands near the face, glasses and overlapping jewelry.
- Devices: test current Safari on iPhone, Chrome on Android and desktop browsers, including lower-powered devices. Measure latency, frame rate, heat and battery usage.
- Permissions: cover deny, dismiss, revoke, camera disconnected, camera busy, iframe restrictions and insecure URLs.
- Reliability: cover blocked model downloads, slow connections, inference timeout, repeated start/stop, background tabs and resizing.
- Fit diversity: evaluate a consented and appropriately representative range of faces, ears, skin tones, hairstyles and body shapes.
- Privacy: inspect actual network traffic before making a production privacy claim. Confirm analytics and third-party scripts do not capture images or landmarks.
Validation of this delivery: source syntax, local asset references and automated geometry/worker contract checks are recorded with the project. Physical-camera accuracy and real iPhone/Android performance have not been verified. Desktop Chromium phone-size viewport checks and model-photo inference were performed. Those checks are required before calling this production-ready. WebMCP selection, read-back and intentional invalid-product rejection have now been verified in the browser. Sample-photo inference and product-detail controls were also inspected.
8. Suggested implementation sequence
- Interaction prototype — this demo: validate camera flow, category selection, layering and placement controls.
- Measured 3D pilot: implement a small real catalog, calibrated anchors and a 3D rendering pipeline.
- Fitting and occlusion: develop ear and neck-specific tracking and evaluate it on a consented test set.
- Store integration: connect catalog, variants, storefront entry points and analytics that exclude camera data.
- Production hardening: complete device coverage, fallbacks, quality gates, privacy review and monitored rollout.
Time and budget should be estimated after choosing the target devices, acceptable fitting error, catalog size and asset source. Dedicated computer-vision work and 3D asset production are significant workstreams, not just website styling.
Hostinger release: 14 September 2026
This package includes eight GLB models and the eight supplied PNG references. It uses static HTML/CSS/JavaScript and needs HTTPS, but no Node.js hosting or API key. Each product detail dialog links to its model and source reference. The mobile mirror remains visible while browsing, and the fit panel includes session-local per-ear anchor refinement. Comparison and removal controls were exercised in the browser. The supplied render references establish front shapes, not hidden construction or measured scale.
Reference study and product-detail update
Sources and credits
- Google: Face Landmarker for Web — model outputs, configuration and worker guidance.
- Google: Pose Landmarker for Web — pose inference and landmark outputs.
- MDN: getUserMedia — secure contexts and camera permission.
- Mirrar — the user's reference for the virtual try-on service category; no affiliation or code reuse.
- Sample portrait by Raamin ka on Unsplash, under the Unsplash license.
- Models 02–04: AI-generated studio portraits created for this demo; they do not depict supplied customers.
- Three.js physical materials — reflective rendering and environment maps. See bundled MIT license.
The supplied YouTube page could not be retrieved, so no video-specific features or performance claims are attributed to it.