Fyndr — AI-Powered Event Photo Sharing
Production-grade event photo-sharing platform for photographers and guests: SCRFD face detection, ArcFace 512-d embeddings, per-event FAISS indexing, multi-stage image processing pipeline, and privacy-first ephemeral search.
Timeline
2025 — 2026
Role
Solo — full stack architecture, ML inference pipeline, frontend, vector search
Status
In-progressTechnology Stack
Key Challenges
- Balancing face recognition accuracy with low-latency inference on cost-effective CPU infrastructure
- Filtering false positives (crowd backgrounds, motion blur, extreme angles) before computing vector embeddings
- Designing high-throughput bulk uploads and multi-resolution image derivatives without blocking web workers
- Preserving guest privacy with ephemeral selfie processing and automated event lifecycle expiration
Key Learnings
- Pre-filtering by Laplacian blur variance (>80) and face bounding box size (>45px) cuts 25% false positives and saves 30% embedding computation
- Downsampling high-resolution 45MP event photos to 640px analysis derivatives via libvips cuts pixel processing by 50× while staying in SCRFD detection sweet spot
- Per-event FAISS IndexFlatIP vector indexes provide sub-20ms exact cosine similarity searches across thousands of face vectors with zero cross-event index pollution
- A composite re-ranking score (0.7 cosine similarity + 0.2 detection confidence + 0.1 normalized face size) significantly improves guest photo recall in variable event lighting
Overview
Weddings and corporate events regularly generate 5,000 to 50,000 high-resolution photos (often 10 GB to 50 GB+). Traditional delivery forces guests to wait weeks for a massive ZIP archive or endlessly scroll through tens of thousands of candid shots to find themselves.
Fyndr solves this for photographers and guests through instant facial recognition:
- The photographer creates an event and uploads raw photos.
- Guests scan an event QR code and snap a single 3-second selfie on their phone (no app download or account creation required).
- The platform detects faces, generates 512-dimensional ArcFace vector embeddings, queries a per-event FAISS vector index, and immediately displays a personalized masonry gallery containing only photos that feature that guest.
Recognition & Search Pipeline
The image pipeline balances high recognition accuracy against compute cost by executing four specialized stages:
Pipeline Stages Breakdown
| Step | Engine | Input → Output | Technical Purpose |
|---|---|---|---|
| 1. Preview | libvips / sharp | 45MP (8 MB+) → 640px (300 KB RGB) | Eliminates 50× raw pixel processing; targets SCRFD optimal detection scale |
| 2. Detection | SCRFD-320 (buffalo_s) | 640×640 → Bounding boxes + 5 landmarks | High-speed multi-scale face localization with Non-Maximum Suppression (NMS) |
| 3. Quality Gate | OpenCV / NumPy | Crop evaluation | Discards boxes with confidence < 0.6, dimensions < 45px, or Laplacian blur variance < 80 |
| 4. Alignment & Embedding | ResNet-50 ArcFace | 112×112 aligned crop → 512-d vector | Pre-trained on WebFace600K; outputs L2-normalized vector embedding |
| 5. Vector Search | FAISS (IndexFlatIP) | 512-d query → Top-48 matches | Sub-20ms exact inner product search (O(N) dot products) over per-event vector space |
Key Technical Decisions
1. 512-d ArcFace vs. 128-d Legacy Embeddings
Traditional web solutions rely on client-side 128-dimensional models (face-api.js or dlib), which suffer high false-positive rates in dimly lit banquet halls, profile angles, and crowded backgrounds. Switching to 512-dimensional ArcFace embeddings increased verification accuracy to 89.8% MR-ALL at FAR 1e-6, drastically minimizing false accepts.
2. Quality Gates Before Neural Embedding
Computing ArcFace embeddings on distant crowd background blur wastes valuable CPU/GPU cycles. Implementing three deterministic quality checks prior to feature extraction—detection confidence (>= 0.6), minimum face size (>= 45px), and Laplacian blur variance (>= 80)—eliminates 25% of background noise and saves 30% of embedding computation time.
3. Per-Event FAISS Vector Isolation
Rather than pooling face vectors from all events into a monolithic vector database, Fyndr maintains dedicated IndexFlatIP instances partitioned by event_id in /tmp/fyndr_faiss/event.index. This guarantees zero cross-event data leakage, simplifies cache invalidation, and keeps search queries sub-20ms.
4. Re-Ranking Composite Score
Raw cosine similarity can favor well-lit incidental background faces over slightly rotated foreground subjects. A composite ranking heuristic weights the match:
Score = 0.7 * CosineSimilarity + 0.2 * DetectionScore + 0.1 * (FaceSize / 2048)Results are deduplicated per photo, retaining only the highest-scoring face match.
Privacy & Data Protection
- No Guest Accounts: Guests access events via transient PIN/token sessions; no personal data or email is collected.
- Ephemeral Selfies: Guest verification selfies are processed entirely in memory or temporary storage and deleted within 60 seconds of vector generation.
- Automated Expiration: Event catalogs, vectors, and image caches automatically expire and are purged 90 days post-event.
Tech Stack Summary
- Frontend: React 18, React Router, Tailwind CSS, Masonry Layout
- API Backend: Node.js 20, Express, Mongoose, JWT, Multer
- Machine Learning: Python 3.10, Flask, InsightFace (
buffalo_s), ONNX Runtime, FAISS - Database & Storage: MongoDB 8.0, local filesystem / S3-compatible object storage