Finding-missing-person-using-AI: a Streamlit face-matching demo with a KNN matcher and a public sighting portal

The problem it targets: manual photo comparison between a report and a sighting

The README frames the problem in one paragraph: people, mostly children, go missing daily in India, and when a sighting is reported, officers compare photos by hand and coordinate across stations until the trail goes cold. That is a real workflow bottleneck, and the repository's answer is narrow on purpose. It does not attempt dispatch, case law, or inter-station messaging. It replaces one step, the visual comparison of a reported photo against a submitted sighting photo, with a landmark extraction and a nearest-neighbour lookup.

The intended user is visible in the role table. An Admin registers cases, views all cases, triggers matching, and can edit or delete records. An Officer registers cases and views only their own. A third surface, mobile_app.py, is a public portal with no login where anyone can submit a sighting. That three-way split tells you who the author imagined: a police station with a small number of staff and a public that occasionally recognises someone. The topics list includes college-project and final-year-project, and the README asks readers to endorse the author on LinkedIn, so the primary audience is closer to a reviewer or a student than a procurement officer.

From uploaded photo to 468-point mesh to a 1,404-dimensional vector

The pipeline is described in four numbered steps in the README. An officer uploads a photo, MediaPipe Face Landmarker detects the face and extracts a 468-point mesh. A public sighting uploads a photo or a video, and the same extraction runs, with the README stating that unique faces are extracted per frame for video. An admin then triggers matching, and a KNN model compares sightings against open cases.

The arithmetic behind the vector size is not spelled out, but it is consistent: 468 landmarks multiplied by three coordinates gives 1,404 values, which is the dimensionality the features table quotes. So each face becomes a single row of 1,404 floats, and matching is a distance computation in that space. KNN here is doing template comparison, not classification, which is why the interface can show a confidence percentage rather than a class label.

Two consequences follow from that design. First, the matcher is only as good as the landmark detector, so a profile shot, a heavy occlusion, or a low-resolution CCTV frame degrades the vector before KNN ever runs. Second, there is no threshold tuning described in the README. It says a face that is close enough flips the case to Found and notifies the complainant by email, but it does not state where the cutoff lives, whether it is a config key, or whether it is hardcoded. If you adopt this, that is the first constant you will want to find.

Two Streamlit apps, one SQLite file, and an auto-downloaded model

Getting it running is short. The README gives these commands:

git clone https://github.com/gaganmanku96/Finding-missing-person-using-AI.git cd Finding-missing-person-using-AI pip install -r requirements.txt streamlit run Home.py streamlit run mobile_app.py

Home.py is the officer and admin portal, mobile_app.py is the public submission page. The README states that the SQLite database and the face landmarker model, roughly 30 MB, are created or downloaded automatically on first use. That means the first run needs network access even though nothing in the setup commands suggests it.

Email alerts are optional and gated on four environment variables: SMTP_HOST, SMTP_PORT, SMTP_USER, SMTP_PASSWORD. The recipient is the complainant's email captured during case registration, so the notification path depends on that field being filled correctly at intake.

One inconsistency is worth flagging before you spend time on it. The repository description says the project uses a Postgres database, while the README badge and the setup text both say SQLite. The README is the more specific source and it is describing the runtime, so treat SQLite as the working assumption and verify against the code. If you were planning to run this against a shared Postgres instance because of the description, you will need to reconcile that yourself.

Credentials live in login_config.yml, and roles are coarse

Authentication is file-based. The README instructs you to generate a bcrypt hash with bcrypt.hashpw(b"your_password", bcrypt.gensalt()).decode() and paste it into login_config.yml under credentials.usernames. Each entry carries name, email, city, area, role, and the password hash. The file is git-ignored by default, and the README warns not to commit real credentials.

The role model has exactly two values. Admin can register, view all cases, trigger matching, and edit or delete. Officer can register and view their own cases. There is no auditor role, no read-only investigator, and no separation between the person who triggers a match and the person who confirms it. For a demo that is fine. For anything resembling a real intake process, the ability of an Admin to delete a case without a trace is the kind of gap that matters more than the matching accuracy.

A second detail: the city and area fields are attached to the user, not necessarily to the case. If an Officer's own-case view is scoped by those fields, then a reassignment or a transfer changes what that account can see. The README does not describe how scoping is implemented, so this is something to read in the code rather than assume.

Seed data comes from a DuckDuckGo image scraper

The scripts folder holds utilities for populating the database. The README shows:

uv run scripts/download_celebrity_images.py --dest reported uv run scripts/download_celebrity_images.py --dest both

The first pulls roughly two images per celebrity into scripts/bulk_data/reported/. The second splits them across reported and publicly_seen, which is the shape you need to exercise the matcher end to end. The README notes this uses DuckDuckGo image search and needs no API key.

Using celebrity photos as a stand-in for missing-person reports is a reasonable way to get a working demo without real personal data, and the README's disclaimer says the sample images were sourced from the internet for non-commercial educational demonstration only, with a takedown offer via an issue. That is a sensible posture for a college project. It is also a hard boundary on what you can do with the repository: the disclaimer explicitly frames the use as non-commercial and educational, and the repository carries no licence file.

That missing licence is the practical constraint. Without one, the default is that the author retains all rights, which means you cannot assume permission to redistribute, modify, or ship this in a product. The disclaimer governs the sample images, not the code, so it does not fill the gap. If you want to reuse the pipeline, the honest move is to read the code and reimplement the parts you need under your own licence, or contact the author.

Where the design breaks: no threshold, no deduplication, no audit trail

The most likely failure mode is a false positive that flips a case to Found. Landmark vectors from MediaPipe encode geometry, not identity. Two people with similar face proportions, or one person photographed at different angles with different lighting, can land close together in 1,404-dimensional space. Because the README describes an automatic status flip and an automatic email on match, a single spurious match produces a notification to a family that their case is resolved. There is no described human confirmation step, and no described way to mark a match as a false positive.

A second issue is deduplication. The README says video sightings extract unique faces per frame, but it does not describe how uniqueness is decided. If that check is weak, one video of one person can insert many near-identical vectors, which inflates the sighting set and changes what KNN sees on the next run.

A third is scale. KNN against every open case on every refresh is linear in the number of stored vectors. That is invisible at demo size and becomes the bottleneck once the sighting table grows, because there is no described indexing or approximate nearest-neighbour structure. The right tool for a production version of this would be a vector index with a tunable recall and a distance threshold, not a brute-force scan. This repository is not that, and it does not claim to be.

What a real deployment would swap in, and why the difference matters

The obvious alternative is a dedicated face-recognition library such as face_recognition or a face-embedding model served through a vector index. The difference is not brand preference, it is what the vector represents. MediaPipe Face Landmarker returns 468 geometric points: where the eyes, nose, jaw, and mouth sit relative to each other. That is a shape descriptor. Face-recognition embeddings are trained so that the same identity maps to a nearby point and different identities map far apart, which is what makes a fixed distance threshold meaningful.

With landmarks, you can compute distances and rank them, which is exactly what this project does, and it works well enough to demonstrate the flow. But you cannot easily say "below this number means the same person," because the metric was not trained for that question. A second practical difference is robustness to pose and lighting. Landmark extraction degrades when the face is turned or shadowed, while embedding models are typically trained with augmentation for those conditions. A third is that embeddings come with a known dimensionality and a known similarity metric, so swapping in an approximate index later is a configuration change rather than a redesign.

None of that makes the current approach wrong for its stated purpose. It makes it a demonstration of the plumbing, which is what the README describes.

Maintenance cost and the licence question you have to answer first

There are no releases in the retrieved material, so there is no versioning scheme to track and no changelog to read before upgrading. The last push is dated 2026-03-13, which tells you the repository is not abandoned, but with no releases and no tags, an upgrade means pulling the default branch and diffing it yourself. Two Streamlit entry points, a SQLite file, a YAML credential store, and a scripts folder are the whole surface, so the codebase is small enough to read in a sitting. That is the maintenance story: low volume, no release discipline.

The dependency risk sits with MediaPipe and Streamlit rather than with the project's own code. MediaPipe model downloads and API surfaces change between versions, and the README says the landmarker model is auto-downloaded on first use, so a pinned requirements.txt is doing more work here than in a typical app.

On licensing, the repository states no licence, and the README's disclaimer covers only the sample images. I am not giving legal advice, but the practical reading is that you have no granted rights to the code. If your plan involves redistribution or a commercial deployment, resolve that before writing any integration code, not after.

Editorial conclusion

Adopt this if you want a readable reference for wiring MediaPipe landmarks into a KNN matcher behind two Streamlit apps, or if you are a student who needs a working demo with seeded data. Do not adopt it if you need an auditable chain of custody, consent handling, or a licence you can redistribute under, because the repository states no licence at all. Before running anything, confirm which database file the code actually opens, since the README describes Postgres in the project description and SQLite in the badge and setup text.

Official sources

1. gaganmanku96/Finding-missing-person-using-AI on GitHub
2. Issues
3. README