BUG
detectFacesAndLiveness() recognition logic
The code calculates attendance for ANY blink from a recognized face, not just a single intentional blink. Rapid blinks or continuous detection could mark attendance multiple times within the cooldown period.
💡 Require at least 1-2 consecutive blinks with a specific timing pattern to confirm liveness. Alternatively, increase the cooldown period or implement a state machine that tracks 'ready to mark' vs 'already processing' states.
BUG
enrollKnownFaces() face detection
If any enrolled face image fails to load or doesn't contain a valid face, the descriptor array and names array become misaligned (different lengths), causing parseInt(bestMatch.label) to access the wrong name.
💡 Track indices separately or store {name, descriptor} objects in a single array instead of parallel arrays. Or add validation that ensures both arrays stay synchronized.
STYLE
Global variables and function organization
Many global variables (blinkCounter, isBlinking, lastBlinkTime, etc.) related to blink detection could be grouped into a single object or class for better organization and readability.
💡 Consider refactoring: `const blinkState = { counter: 0, isBlinking: false, lastTime: 0 };` and access as `blinkState.counter` to make code more maintainable.
FEATURE
markAttendanceLocal() and displayAttendanceReports()
The system marks attendance only once per day per person, but there's no way to review or manage individual attendance records (edit, delete, or re-mark).
💡 Add UI buttons in the reports modal to allow instructors to manually mark/unmark attendance, edit timestamps, or export data as CSV.
FEATURE
enrollment process
Known faces are hardcoded as image URLs and must be loaded from the web. There's no UI to add new students dynamically without editing the code.
💡 Add a webcam-based enrollment feature where instructors can click a 'Enroll New Student' button, provide a name, and the system captures their face directly from the webcam to compute and store their descriptor.
FEATURE
displayAttendanceReports()
Reports show absolute dates but don't track which sessions are 'expected' vs 'actual.' If students attend only 2 of 3 sessions, the percentage is 66%, but it's unclear if a session was skipped or not offered.
💡 Add a 'Sessions' column showing which specific dates are tracked, and let instructors mark 'no class' days so the denominator properly reflects actual expected attendance days.