The final project in this arc is the most science-fiction sounding thing I have built, a desktop application that watches two cameras, one at an entry, one at an exit, recognises the faces it sees, and logs who passed, when, and which way. An attendance and activity logger with eyes. This post is the idea, the honest scope decisions made before any code, and the architecture that made a solo build of this possible at all.
The requirements, as specified for the real build. Two USB cameras processed in real time, entry and exit. Recognition against a local set of known faces that an admin can grow, add a person with their name and a photo. Every recognition logged, name, date, time, camera, and a captured image, into a local SQLite database with search, filters, and CSV export. Alerts when an unknown face appears. A desktop interface showing live previews and the logs. Windows and Linux, including modest hardware. And the whole thing packaged as an executable, under a line budget, with the modules separated cleanly, interface, logic, database, recognition.
The scope honesty came first, because face recognition is a field where overpromising is the default. This is a small-scale system, a known-faces set measured in dozens for a shop, an office, a family gate, not a thousand-person enterprise deployment. It matches faces, it does not judge liveness, so it is a logger and assistant, not a security barrier, a distinction the accuracy post makes concrete. And it runs entirely locally, faces, encodings, logs, and images never leave the machine, which for something this sensitive is not a limitation but the design, surveillance of your own doorway should not route through anyone’s cloud.
The architecture followed the requirements’ natural joints, four modules, and sketching them as the program’s actual skeleton was the first code written:
# the system's real shape, one module per concern
# FaceRecognizer loads known faces, encodes, matches (recognition module)
# CameraManager one per USB camera, threaded capture (camera module)
# DatabaseManager SQLite logs + known faces + CSV export (database module)
# FaceRecognitionApp Tkinter tabs: Live Cameras | Logs | Admin (interface)
class FaceRecognitionApp:
def __init__(self):
self.db = DatabaseManager('face_recognition.db')
self.recognizer = FaceRecognizer('known_faces/')
self.entry_cam = CameraManager(0, 'Entry', self.recognizer, self.db)
self.exit_cam = CameraManager(1, 'Exit', self.recognizer, self.db)
Four modules that the whole series walks through. A recognition module wrapping the face_recognition library, the next post’s subject, with the encodings that make matching work explained in the one after. A camera module running each camera in its own thread, because two live streams and an interface cannot share one thread, the threading post’s subject. A database module owning the SQLite logging and export. And a Tkinter interface with tabs for live cameras, logs, and admin, the shape inherited from the shop software, tabs by job, the daily screen first. Everything after this post is those modules meeting reality.
A few things people ask me about this
Does this need special cameras or hardware? Ordinary USB webcams, and a normal computer. Frame sizes and processing rates are chosen for modest hardware, the threading post shows the exact settings that keep it smooth.
Is a homemade system like this legal to run? On your own premises, monitoring your own entry, generally yes with signage and consent rules varying by place, know your local law. Recording strangers or public space is a different matter entirely, this system is designed for your own doorway.
Next
The recognition itself stands on a library that made this whole field accessible to solo builders. That library, and the standing-on-shoulders decision, is the next post.