Smart Attendance System with Face Recognition

Page 1⤢Page 2⤢Page 3⤢Page 4⤢Page 5⤢Page 6⤢Page 7⤢Page 8⤢Page 9⤢Page 10⤢Page 11⤢Page 12⤢

+59

more pages in the ZIP

Showing the first 12 pages of 71. Tap any page to read it full size — this is the actual Word file you get, not a mock-up.

dashboard⤢students⤢enroll⤢live⤢register⤢recognition⤢subject report⤢defaulters⤢classes⤢

Tap any screenshot to open it full size. These are from the project actually running — not mockups.

A working attendance system that marks a class present from a camera. The teacher opens a period, the camera looks at faces, and the register fills itself - and wherever the machine is unsure, the teacher fixes it with one click and that change is recorded as a manual one.

The recognition is not a wrapper around a tutorial. Faces are found with OpenCV's YuNet detector and turned into 128 numbers by OpenCV's SFace model, both of which ship inside opencv-python. That single decision is why this project installs in one command: the usual dlib / face_recognition route needs CMake and a C++ compiler on Windows, and that is exactly where most students give up.

Every threshold in the code was measured, not guessed. The evaluation folder runs ten studies on LFW - 311 people, 5,425 real photographs - and writes results.json, which is where config.py gets its numbers from. The match threshold of 0.371 is the point where a wrong acceptance happens less than once in a thousand comparisons while a correct face is still accepted 98.5% of the time, because in attendance those two mistakes are not equally expensive: a wrong acceptance means somebody marked another student present and nobody ever finds out, while a wrong rejection just means standing in front of the camera again.

The studies also changed the design twice. Averaging a student's enrolled photos into one template instead of keeping them separate cut the rate at which a stranger gets somebody's name from 26.1% to 16.8%. And skipping landmark alignment - the single line most tutorials leave out - drops accuracy from 100% to 77% and produces 19 wrong names out of 100, which is the kind of failure that never announces itself.

What the system cannot do is written into the README rather than hidden: a printed photograph gets marked present 99.2% of the time. A passive liveness check was built, measured, found to catch 0% of print attacks, and deliberately left out of the product, because a security feature that does not work is worse than none. The system is built to run in front of a teacher, and every scan is written to an audit log so a disputed attendance can actually be settled.

• ✓Live attendance from a camera - a recognised student is marked the moment they are seen
• ✓Group-photo attendance too: webcam and uploaded photo go down exactly the same path
• ✓Every number was measured: 10 studies over 311 people and 5,425 real photographs (LFW)
• ✓Match threshold 0.371, chosen at a false-accept rate of 0.1% rather than by feel
• ✓One averaged template per student - this alone cuts a stranger being given a name from 26.1% to 16.8%
• ✓Landmark alignment: without it accuracy falls from 100% to 77% and 19 wrong names appear (measured)
• ✓Three gates on enrolment: exactly one face, a sharp well-lit photo, and no face already on somebody else
• ✓The duplicate check has its own stricter threshold (0.50) - a loose one blocks real students
• ✓One entry per student per period, enforced by a DATABASE constraint and not by an if
• ✓The teacher's manual decision overrides the camera, and is recorded as TEACHER
• ✓Full scan audit log - this is what settles a disputed 'my attendance did not get marked'
• ✓Matching is scoped to one class, never to the whole college
• ✓Closing a period marks the rest absent without touching anyone already present
• ✓AKTU 75% rule with a defaulters list and CSV export
• ✓A student can only see their own attendance - the route has no id in it at all
• ✓A face is stored as 128 numbers (512 bytes), not as a photograph
• ✓Deleting a student deletes their biometric data too, and there is a test proving it
• ✓CSV import for a whole class list
• ✓PBKDF2-SHA256 password hashing with a per-user salt
• ✓Every query parameterised; a SQL injection attempt is part of the test suite
• ✓check_setup.py tells you what is wrong AND what the next step is
• ✓48 automated self-tests that need no camera and no internet
• ✓No dlib, no CMake, no CDN - one pip install and it runs
• ✓What the system cannot do is stated plainly in the README instead of being hidden

• • Python 3.8+
• • Flask (web framework)
• • OpenCV (face detection + recognition, no dlib needed)
• • MySQL / MariaDB (XAMPP works out of the box)
• • PyMySQL (database driver)
• • NumPy
• • VS Code (or any editor)
• • Any web browser with a camera

Python 3.8 or newer, and MySQL. XAMPP is the easiest way to get MySQL - install it, open the Control Panel and press Start next to MySQL. Then one command installs the libraries: pip install -r requirements.txt (OpenCV, NumPy, Flask and PyMySQL, about 70 MB). Nothing compiles, so no C++ build tools are needed on Windows. The two face models ship inside the ZIP, so no download is required. The database and all its tables are created automatically on first run - there is no .sql file to import. A webcam is optional: every screen also accepts an uploaded photo. Works on Windows, Linux and Mac.

1. Extract the ZIP.
2. Start MySQL - open the XAMPP Control Panel and press Start next to MySQL.
3. Open CMD and go to the folder:  cd path\to\attendance-face-recognition
4. Install the libraries:  pip install -r requirements.txt
5. Check everything is ready:  python check_setup.py
6. Load the demo data:  python demo.py
7. Start the app:  python app.py
8. Open http://127.0.0.1:5000 in your browser.
9. Login:  admin / admin123   (administrator)   or   teacher / teacher123

If MySQL uses a password on your machine, set it once before step 5:
    set AFR_DB_PASSWORD=yourpassword

Important: open the app as http://127.0.0.1:5000 on the same machine. Browsers only give camera access on https or on localhost, so opening it by LAN IP will show no camera - in that case use the photo-upload option on the same screen, which does exactly the same work.

Before a viva, also run 'python selftest.py' - 48 checks pass in front of the examiner, with no camera and no internet.

The same steps are in README.md inside the ZIP, along with a troubleshooting table.

• 📁 Full source code — commented throughout, so you can explain it in the viva
• 🗄️ Database — the schema builds itself on first run, with sample data
• 📖 README.md — step-by-step run instructions, database design and troubleshooting
• 📄 Full project report (Word) — Written out and formatted for AKTU — not an outline you have to fill in
• 📊 Presentation (PPT) — Ready for the final viva presentation
• 📝 Synopsis (Word) — The short write-up your guide asks for before approval
• ❓ Viva questions with answers — The questions examiners actually ask about this project
• 📐 21 ready-made diagrams — DFD, ER, use case, sequence and architecture, as images you can paste straight into the report