Open Source Face Recognition SDK

Abstract

Face Recognition, Face Liveness Detection, Face Anti-Spoofing, Face Detection, Face Landmarks, Face Compare, Face Matching, Face Pose, Face Expression, Face Attributes, Face Templates Extraction, Face Landmarks

The Problem

Face recognition typically means sending biometric data to a cloud API, which creates privacy, latency, and compliance problems for access control, kiosks, and identity verification. This SDK positions itself as a fully on-premise alternative: detection, landmarking, and feature extraction all run locally with no network calls.

What This Does

It is a Python face pipeline built on PyTorch. face_detect/ contains an SSD-style detector (mb_tiny_RFB_fd.py, ssd.py, predictor.py) with pretrained weights in face_detect/models/pretrained/version-slim-320.pth. face_feature/GetFeature.py extracts embeddings via irn50_pytorch.py (weights in irn50_pytorch.npy). face_landmark/GetLandmark.py runs MobileFaceNet.py with vfl_1.02_578_6.734591484069824.pth.tar. face_util/faceutil.py wraps compiled C libraries (FaceUtil.dll, libFaceUtil.so) for the heavy lifting. The README claims liveness, anti-spoofing, expression, and attribute support, but the file structure only shows detection, landmarks, pose, and feature extraction.

How It Is Wired

Execution starts at run.py. It calls into face_detect/detect_imgs.py to get bounding boxes, then face_feature/GetFeature.py for embeddings, face_landmark/GetLandmark.py for landmarks, and face_pose/GetPose.py for pose angles. Similarity comparison routes through face_util/faceutil.py, which calls into the native DLL/so. The README's quick-start imports from face_recognition_sdk import FaceRecognition, but no such module exists in the file listing — the documented API does not match the actual code, so a reader following the README will hit an import error. The real API surface is whatever run.py and faceutil.py expose. Binary weights and native libraries are committed directly to the repo, so there is no model download step, but also no provenance or rebuild path for those artifacts.

How To Use It

The README documents these steps verbatim:

conda create -n facesdk python=3.9
conda activate facesdk
pip install -r requirements.txt
python run.py

There is no config file and no documented environment variables. The only runtime inputs are the test images in test/ (1.jpg, 2.png). The README's GetImageInfo(image_path, faceMaxCount) and get_similarity(feature1, feature2) calls are the intended interface, but they are not importable as shown — you would need to read run.py to find the actual callable names.

Real-World Use

A lobby kiosk that enrolls an employee's face once, stores the embedding locally, and compares each new capture against it on the same machine. No biometric data leaves the device, which keeps the deployment inside the privacy boundary a customer's security team would demand. The pipeline is: detect face → extract embedding → compare against stored template with a similarity threshold (the README uses 75).

Code Health & Issues

High - README API mismatch - the documented face_recognition_sdk import and FaceRecognition class do not exist in the file structure; the actual entry is run.py.
Med - No CI/CD - no .github/ or CI config, so nothing gates regressions.
Med - No LICENSE file - the README claims "open source" but the repo ships no license terms; redistribution rights are unclear.
Med - No automated tests - the two "test" files are images (test/1.jpg, test/2.png), not test code.
Low - No dependency lockfile - only requirements.txt, so installs are not reproducible.
Low - Binary artifacts in git - .pth, .npy, .dll, and .so files are committed; repo size and provenance are concerns.

The Bottom Line

A functional demo of the upstream Faceplugin pipeline (2008-star parent repo) with the core detect → embed → compare flow intact. The README oversells the API surface and the license is ambiguous, so treat it as a reference implementation for wiring a local face pipeline, not as a drop-in SDK. Before production use, align the documentation with the real entry points and confirm licensing with the upstream project.

What the analyser found

Deployment readiness

3/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

38 files

Python27
Markdown1

PyTorch

Module dependencies

The 10 most depended-upon modules of 27, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_detect_vision_utils___init__["__init__"] n1__detect_vision_ssd_predictor["predictor"] n2_face_detect_vision_ssd_ssd["ssd"] n3_t_vision_ssd_config___init__["__init__"] n4_ace_detect_vision_utils_misc["misc"] n5_face_util_faceutil["faceutil"] n6_ct_vision_ssd_mb_tiny_RFB_fd["mb_tiny_RFB_fd"] n7_detect_vision_ssd_mb_tiny_fd["mb_tiny_fd"] n8_face_detect_detect_imgs["detect_imgs"] n9_face_feature_GetFeature["GetFeature"] n8_face_detect_detect_imgs --> n7_detect_vision_ssd_mb_tiny_fd n8_face_detect_detect_imgs --> n6_ct_vision_ssd_mb_tiny_RFB_fd n6_ct_vision_ssd_mb_tiny_RFB_fd --> n3_t_vision_ssd_config___init__ n6_ct_vision_ssd_mb_tiny_RFB_fd --> n1__detect_vision_ssd_predictor n6_ct_vision_ssd_mb_tiny_RFB_fd --> n2_face_detect_vision_ssd_ssd n7_detect_vision_ssd_mb_tiny_fd --> n3_t_vision_ssd_config___init__ n7_detect_vision_ssd_mb_tiny_fd --> n1__detect_vision_ssd_predictor n7_detect_vision_ssd_mb_tiny_fd --> n2_face_detect_vision_ssd_ssd n1__detect_vision_ssd_predictor --> n0_detect_vision_utils___init__ n1__detect_vision_ssd_predictor --> n4_ace_detect_vision_utils_misc n2_face_detect_vision_ssd_ssd --> n0_detect_vision_utils___init__ n0_detect_vision_utils___init__ --> n4_ace_detect_vision_utils_misc n9_face_feature_GetFeature --> n5_face_util_faceutil

Dependencies

2 of 6 declared dependencies are a major version behind. Resolved 6 of 6 against the registry.

Package	Declared	Latest	Behind
`pillow`	==10.4.0	12.3.0	2 major
`numpy`	==1.26.4	2.5.2	1 major

Findings

MediumNo CI/CD pipeline detected - no automated build/test gate .github/ or CI config
MediumNo LICENSE file - unclear usage/redistribution rights root
LowDependencies declared without a lockfile - non-reproducible builds requirements.txt

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

critical1

high3

medium2

Upgrade the pinned dependency carrying a critical advisorycritical57 occurrences

pillow@10.4.0 CVE-2026-59198 (critical) +33 more; torch@2.4.1 CVE-2025-32434 (critical) +22 more

The manifest pins the exact version the advisory covers, so this is not a warning about drift: the vulnerable code is what installs, and a critical rating means it is reachable over the network without credentials or user interaction.

Fix: Upgrade to the fixed version named in the advisory, then commit the lockfile.

Add a LICENSE; redistribution rights are undefinedhigh

no licence file at the repository root

Fix: Add MIT or Apache-2.0 at the repository root.

Add a test suite; this repository has nonehigh27 occurrences

27 source files, no test files

Any change ships with no signal that existing behaviour still holds, so a regression reaches production undetected.

Fix: Add one test per public entry point, then a CI step that runs them.

Add a workflow that builds and tests this repositoryhigh

27 source files, no CI configuration

Every change merges with nobody having run the build once, which across this estate is 499 repositories.

Fix: Add a workflow running the project build and test command on push and pull_request.

Enable Dependabot or Renovatemedium

1 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Move large binaries to Git LFS or out of the repositorymedium

face_feature/irn50_pytorch.npy

1 blobs over 5MB: irn50_pytorch.npy 53.7MB

One repository here carries twenty blobs over 5MB including a 10.9MB spreadsheet, so every clone and every CI checkout pays for data nobody diffs.

Fix: Track those extensions with LFS, or move datasets to object storage and fetch them in a setup step.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.