YouCam API Hackathon · Topic C — Skin AI × Apparel VTO
OneDress icon: five skin-tone dots converging on one dress OneDress

Six bridesmaids. Six skin tones. One dress color — provably no one's worst option.

The problem

One color. Final sale.
Chosen by eyeballing a stranger.

i.

One color for every complexion

4–8 women, often spanning Fitzpatrick I–VI, wear the same mandated colorway. The shade that flatters the bride can drain everyone else — in the photos that last forever.

ii.

Usually non-refundable

Ordered months out, frequently final-sale. The color decision is effectively irreversible — there is no "return it if it washes her out."

iii.

Decided by guesswork

Picked from one retailer model who matches nobody in the party. Mailed swatch kits and the "mismatched dresses" trend exist because one-color-for-all keeps failing.

The insight

We inverted the personal-color quiz.

Everyone else asks

"What are my best colors?"

One selfie → one verdict. Run it for five bridesmaids, get five incompatible answers — which chooses zero dresses. Single-user verdicts don't compose into a group constraint.

OneDress asks

"Given one garment all N must wear — which color harms the group least?"

A fixed garment constraint × N measured complexions → one answer. A constrained group-optimization problem no single-user tool can express.

It's a max-of-minimum — Rawlsian — fairness problem. The winner is never any individual's top pick, and by construction the deepest-skin bridesmaid is the protected one, not the sacrificed one.

How it works

Measure. Score. Render. Finish.

01

Measure

Two photos per bridesmaid. Live analyses return her real skin hex, Fitzpatrick I–VI, and face shape.

skin-tone-analysisfitzpatrick-scaleface-attr
02

Score

24 colorways × N profiles, scored by a published formula. Pure math on cached measurements — zero API units to re-score.

deterministic engine31 tests
03

Render

The maximin winner rendered photorealistically on every bridesmaid's own photo — fidelity ΔE00 ≈ 7.7.

cloth-v3
04

Finish

Face shape picks the earring silhouette; undertone picks the metal — gold warm, silver cool — chained onto the render.

2d-vto/earring

The math

Averages hide victims. Minimums protect them.

flatter(p,c) = 0.50·U + 0.30·C + 0.20·S
  U undertone harmony
  C value contrast
  S saturation harmony

groupScore(c) = minₚ flatter(p,c)
winner  = argmax_c groupScore(c)

by-eye  = argmax_c mean flatter
          — how it's chosen today

The by-eye pick

maximize the average

average 68 · worst bridesmaid 39 — Type VI pays for the pretty average

The OneDress pick

maximize the minimum

average 66 · worst bridesmaid 58 — two average points traded for +19 where it hurt most

Illustrative scores, to show the mechanism. In the engine's real measured demo run the maximin winner lands in the dusty-sage / mauve family with nobody below ≈57, while the mean-maximizing pick drops the most-hurt bridesmaid far lower. Full derivation: lib/colorway/engine.ts.

Verified live

Not a mock. Here's the receipt.

EndpointRoleVerified live result
skin-tone-analysismeasured skin hex — the scoring input#bb9982 → ITA° 43 · hue° 61
fitzpatrick-scale-analyzerdepth I–VI cross-checkType II returned
face-attr-analysisface shape → earring silhouette"Heart" returned
cloth-v3winner rendered on each bridesmaidphotoreal · ΔE00 ≈ 7.7
2d-vto/earringchained finishing touchgold hoop landed on the render
5/5endpoints proven end-to-end, one command: npm run spike
43units — measured cost of a full single run
31passing tests on the published engine
0units to re-score all 24 colorways

Sponsor fit

Topic C, actually combined — Skin AI drives the VTO.

Skin AI The measurement half

  • skin-tone-analysis — the hex every score is computed from
  • fitzpatrick-scale-analyzer — the inclusivity axis, I–VI
  • face-attr-analysis — face shape steers the finish

Apparel VTO The proof half

  • cloth-v3 — the winner on every real bridesmaid
  • 2d-vto/earring — chained; undertone picks the metal

Deliberately beyond the sponsor's own surface: Perfect Corp ships personal-color analysis — "what's my season?" for one user. OneDress answers the strictly harder inverse for N people at once. Remove any one endpoint and the flow visibly breaks — the API is the engine, not decoration.

Market & impact

A billion-dollar decision, made by eyeballing one photo.

~2M+US weddings a year — nearly all facing exactly one group color decision
4–5bridesmaids per wedding on average, at ~$100–250 per dress, frequently final-sale
24×Ncolorway-by-complexion combinations no human can eyeball — and today, nobody measures any of them

And the beachhead generalizes: prom groups, quinceañera courts, uniforms, ensembles — every "one garment, many bodies" decision. The maximin objective means the darkest-skin member is protected by construction — inclusivity as an algorithm, not a tagline.

Figures are industry estimates (The Knot Real Weddings Study, retailer pricing); swatch-kit sales and the mismatched-dress trend are the revealed-preference proof the pain is real.

Roadmap

Engine proven. Product in build.

Done & reproducible

  • Live 5-endpoint integration — npm run spike
  • Typed, Zod-validated client — rate-limited, retrying
  • Published scoring engine — 31 passing tests
  • Full CI harness — lint, tests, CodeQL, secret scan

In build → Aug 17

  • 7-step product UI — Create → Verdict
  • Cached zero-unit demo party — instant for judges
  • Counterfactual Compare screen — by-eye vs maximin
  • ≤3-min demo video — live browser, real calls

The ask: judge the mechanism on today's receipts — the inversion, the published math, the five live endpoints. The interactive party lands before the deadline, on this same engine.

Six bridesmaids. One color. Zero arguments.

OneDress — the max-of-minimum dress-color engine, built on the YouCam API.

onedress.edycu.dev · YouCam API Hackathon (Devpost) · Topic C

OneDress

to navigate · P notes · O overview

01 / 10