AI Face Matching System
Automatic player tagging for tournament photos: a GPU face-recognition pipeline that runs unattended.
- ~70%Evidence 1 · ~70% less manual taggingAn estimate: tagging used to be fully manual; now staff review only the matches below the confidence threshold.Go to Resultsless manual tagging
- 512-DEvidence 2 · 512-D face embeddingsEach face becomes 512 numbers (a FaceNet embedding) that are compared to find matches.Go to How it worksface embeddings
No real photos are shown on this page. The system processes images of real people, so everything here is a diagram, and the case study is shared with the client's approval.
Today's queue
- Tagged
- 128 games
- Retrying
- 2 games
- Parked
- 1 game, roster missing
- For review
- 14 faces
The problem
A US youth-sports organization photographs every game, and staff tagged the players in each photo by hand so families could find their pictures. It was slow and repetitive work.
Constraints
- It runs with no engineer watching.
- Corrupt files and missing data are normal, not exceptions.
- Data is spread across three separate databases.
- The business must control how strict matching is.
- Face data is sensitive and has to be handled carefully.
How it works
- Schedulerapscheduler
- Find new games
- Job queueretry budget · lease recovery · parking
- Detect facemtcnn
- Align
- Embedfacenet · 512-d
- Cache
- Detect every facemtcnn
- Embedfacenet
- Compare against the game's team rosters
- Matches for staff review
A scheduler finds new games and puts them on a job queue. Each player’s roster photo is turned once into a face embedding (512 numbers per face) and cached. For every game photo, each face is detected, embedded and compared against that game’s team rosters, and the matches are saved for staff review.
Key decisions
- A job queue built for failure. Every job has a retry budget, so one corrupt photo can’t block the rest. If a run crashes mid-job, its claim expires and the next run takes it over.
- Park, don’t fail. Games with missing data are parked and re-checked automatically on every run, then rejoin the queue once the data shows up.
- Cache embeddings, and respect humans. Roster embeddings are computed once and reused. When a game is re-run, manual corrections by staff are kept, not overwritten.
- Thresholds belong to the business. A 0–100 strictness setting in the database maps to the model’s distance threshold, so staff can tune it without an engineer.
Extension to video: frames are sampled from game video, players are detected with YOLOv8 (exported to ONNX, run with DirectML), player crops optionally go through super-resolution, and then the same face-matching pipeline runs.
Results
- ~70% less manual tagging.
- Runs unattended across three databases, recovering from bad inputs on its own.
What I’d do next
- Replace pair-by-pair matching with a single matrix operation, to make large tournaments much faster.
- Measure precision and recall at each threshold, so the strictness setting maps to known error rates.