VisionID
Face recognition at the edge, where the hardware is whatever the site already had and the interesting problems are not the model.
The problem
Face recognition on a live feed is a solved problem in a notebook and an unsolved one on site. The hardware is whatever is already there — a Jetson on a wall, a desktop with a consumer GPU, occasionally a laptop with neither — and a build that assumes CUDA simply does not start on two of the three. Then the questions stop being about the model: who is allowed to enrol a face, what happens to the faces you did not recognise, and how anyone knows which camera a match came from.
The solution
Inference runs through ONNX Runtime against a priority list of execution providers resolved at load, so CUDA, TensorRT, DirectML and CPU are the same build rather than four deployments. Recognition is cosine similarity against enrolled embeddings with a tunable threshold. Around that sits the part that actually makes it deployable: named camera sources switchable at runtime, three roles behind signed expiring tokens, an operator PIN on destructive actions, and a retention window on unknown faces.
Outcomes
- `PROVIDER_PRIORITY` resolves CUDA → TensorRT/DirectML → CPU at load, so the same artefact runs on a Jetson, a CUDA desktop and a bare laptop with automatic fallback.
- Cosine-similarity matching with a configurable threshold (0.35 by default), tuned for tolerance to slight side profiles rather than frontal-only accuracy.
- Named multi-camera sources: `VIDEO_SOURCES` takes `id=uri` pairs — RTSP or device index — with the active source selectable at startup and switchable while running.
+4 more in the write-up
Inside the write-up
- The model was never the hard part
- One build, four execution providers
- Recognition, and the threshold that is a policy
- The knobs are the performance story
- Who is allowed to do what
- The unknowns need a policy too
- What is deliberately left out