How sasin83/nayan works
1. Overall shape
- This repository is a Django web application wrapped around a separate face-recognition pipeline.
- The web side handles user interaction, pages, and persistence; the Project/ folder holds the computer-vision and enrollment scripts.
2. Django platform boundary
- The Django project lives under Nayan/ with the standard entry points: manage.py, settings.py, urls.py, asgi.py, and wsgi.py.
- This is the main runtime for the browser-facing system and the HTTP request/response layer.
3. Main app module
- The Recognize/ app is the primary Django feature module.
- It contains views.py, urls.py, models.py, forms.py, admin.py, and migrations, which indicates the normal MVC-like Django split: routing, page logic, form handling, and database-backed entities.
4. UI and presentation layer
- Templates are under Recognize/templates/recognize/ and static assets under Recognize/static/recognize/.
- The app includes screens for the landing page, gallery, upload flow, and recognition-related pages such as screens.html and screens_parallel.html.
- This suggests the browser UI is the main operator interface for submitting images and browsing recognized people.
5. Computer-vision / recognition subsystem
- The Project/ directory is the non-Django processing layer.
- Key scripts include:
- Train.py for encoding/training face data
- Recognizer.py for identification
- Register.py for logging recognized faces
- Face Detector.py for face detection
- This subsystem is the core domain engine and is separate from the web app.
6. Data flow from images to identity
- Training uses labeled image files and produces pickle artifacts such as CriminalSet.pk and MissingSet.pk.
- The README notes a filename convention like ID.Name.jpeg, which means identity is derived from file naming rather than a richer metadata system.
- Recognition then consumes those trained encodings to compare an input face against known people.
7. Persistence and artifacts
- The project uses multiple storage forms:
- db.sqlite3 for Django app data
- media/images/ for uploaded or processed images
- pickle files (*.pk) for trained face encodings
- CSV logging via Register.py
- This means the architecture is split between relational app state and file-based machine-learning artifacts.
8. Case categories / output organization
- There are separate data folders for Criminal and Missing faces, including recognized/Criminal and recognized/Missing.
- That implies the recognition pipeline categorizes matches into distinct operational buckets rather than treating all identities uniformly.
9. Operational logging and geolocation
- The README states that when a face is recognized, the system records the device’s IP-based geolocation and writes a dated CSV log.
- Architecturally, this is a side-effect path attached to recognition, not just a classification result.
10. External/runtime dependencies
- The repository is built around Python, Django, and face-recognition tooling that depends on dlib/face_recognition.
- The included Scripts/ folder and Windows executables show the development/runtime setup is Windows-oriented and likely uses a local Python virtual environment.
11. System boundaries to show in a diagram
- A useful diagram should show:
- browser users → Django views/templates
- Django app → uploaded images / SQLite / media files
- Django app → face-recognition scripts in Project/
- training pipeline → pickle model artifacts
- recognition pipeline → logged CSV output and recognized-image folders
12. Architectural summary
- In short: this is a Django front end plus file-based CV backend.
- The web app manages interaction and records; the recognition engine performs training and matching; persistence is split across SQLite, media storage, pickle models, and CSV logs.
Main entry points: views.py Views · Recognizer.py Recognizer · Train.py Train · settings.py settings.py
Components 22
Django web
HTTP entry points, routing, pages, and app logic.
- manage.py · Project command entry for local management tasks.
Nayan/manage.py - settings.py · Project configuration for apps, middleware, and runtime settings.
Nayan/Nayan/settings.py - Project urls · Top-level Django routing for the project.
Nayan/Nayan/urls.py - ASGI/WSGI · Server interface modules for ASGI and WSGI deployment.
Nayan/Nayan/asgi.py
Recognize app
Main Django feature module for recognition workflows.
- App urls · Route definitions for the Recognize application.
Nayan/Recognize/urls.py - Views · Page logic and orchestration for the recognition workflows.
Nayan/Recognize/views.py - Forms · Django form definitions used by the web UI.
Nayan/Recognize/forms.py - Models · Database-backed entities for the application.
Nayan/Recognize/models.py - Admin · Django admin registration for app models.
Nayan/Recognize/admin.py - Templates · HTML screens for landing, upload, gallery, and recognition views.
Nayan/Recognize/templates/recognize - Static assets · CSS, JavaScript, and images used by the interface.
Nayan/Recognize/static/recognize
CV pipeline
Standalone face detection, training, recognition, and logging scripts.
- Train · Builds face encodings from labeled image sets.
Nayan/Project/Train.py - Face detector · Locates faces in source images before recognition or training.
Nayan/Project/Face Detector.py - Recognizer · Compares detected faces against trained encodings.
Nayan/Project/Recognizer.py - Register · Writes recognition events to CSV-like logs and side effects.
Nayan/Project/Register.py
Storage
Database, media uploads, generated artifacts, and output folders.
- SQLite DB · Django application database.
Nayan/db.sqlite3 - Media images · Uploaded and processed images persisted by the web app.
Nayan/media/images - CriminalSet.pk · Serialized encodings for criminal identities.
Nayan/Project/CriminalSet.pk - MissingSet.pk · Serialized encodings for missing-person identities.
Nayan/Project/MissingSet.pk - Recognized output · Categorized recognized-image outputs for criminal and missing cases.
Nayan/Recognize/recognized - CSV logs · Dated recognition records and geolocation side effects.
Other components
- Browser users · People interacting with the web interface.
Connections 23
- Browser users → Project urls: HTTP requests · Users interact with the site through the Django routing layer.
- Project urls → App urls: dispatch · Top-level routes forward app-specific URLs to the Recognize module.
- App urls → Views: routes · App URL patterns map requests to view handlers.
- Views → Templates: render · Views serve the HTML screens for upload, gallery, and recognition flows.
- Views → Forms: validate input · Views use forms to process uploads and submissions.
- Views → Models: read/write · Views coordinate database-backed application state.
- Views → Media images: store images · Uploaded or processed images are persisted under media storage.
- Models → SQLite DB: persist · Django models are stored in the SQLite database.
- Admin → Models: register · Admin exposes model entities for management.
- Views → Recognizer: invoke · Web actions hand off recognition work to the CV pipeline.
- Views → Train: trigger training · The web layer can initiate or depend on training artifacts.
- Train → Face detector: detect faces · Training depends on face detection before encoding images.
- Train → CriminalSet.pk: build encodings · Training produces criminal face-encoding artifacts.
- Train → MissingSet.pk: build encodings · Training produces missing-person face-encoding artifacts.
- Recognizer → CriminalSet.pk: load model · Recognition compares against criminal encodings.
- Recognizer → MissingSet.pk: load model · Recognition compares against missing-person encodings.
- Recognizer → Register: log match · Recognition hands off successful matches for logging.
- Register → CSV logs: append · Recognition events are written to dated CSV-style logs.
- Recognizer → Recognized output: write outputs · Matched faces are organized into categorized output folders.
- settings.py → SQLite DB: configures · Project settings bind the app to its database and storage paths.
- settings.py → Media images: media config · Project settings define media handling for uploads and processed files.
- manage.py → settings.py: bootstrap · Manage entrypoint loads project settings for commands and local runtime.
- ASGI/WSGI → Project urls: serve app · Deployment entrypoints expose the Django project to the server.