Video Analytics, Video Surveillance, AI Live Insight

Finding Every Recording a Person Appears In

Finding Every Recording a Person Appears In

Some investigations open with the answer already in hand. There is a name, and there is a photograph, taken from a previous incident, a personnel record or a case file somebody kept. What is missing is any way for a hundred cameras to act on either. The photograph sits in a folder and the cameras record what passes in front of them, indifferent to the fact that anyone is looking. Closing that gap is what enrolment does, and the mechanics of it decide whether the result is usable a year later or a list nobody trusts. This sits under our guide to multi-camera triangulation, which covers connecting separate sightings of the same thing into a route.

What a gallery record actually holds

Enrolment is often described as adding a photograph, which undersells what the record carries and why each part of it is there. A subject holds a name and one or more reference photographs, which is the part everybody expects. It also holds an external identifier, tying that subject to a record in another system such as a case number, an employee ID or a license record. Without it the gallery becomes a separate list of names that cannot be reconciled with the file the investigation lives in. Reconciling two lists by hand is how the wrong person ends up flagged.

It holds a priority, saying how much this subject matters relative to everyone else enrolled. A gallery of four hundred without priorities produces a flat stream of equally urgent alerts, which is operationally identical to having none. And it holds tags and a description, which exist for searching the gallery rather than searching footage. A list of twenty can be read down. A list of six hundred cannot, and the difference arrives sooner than most teams plan for.

More reference photographs help, and the useful ones are different rather than simply more numerous. What adds most is variety in angle, in lighting and in distance. Each one adds something for the system to compare against, so a single passport-style image is the weakest place to start from.

Listing a vehicle works differently

Listing a vehicle in advance serves the same purpose and uses a different mechanism, which is worth knowing before anyone assumes one behaves like the other. A person is enrolled as a subject with reference photographs, and a match is made by comparing what a camera saw against those images. A vehicle is listed by its plate, and a match is made by comparing text that was read off the plate against the string you entered. One is a comparison of appearance. The other is a comparison of characters.

They fail differently as a result. A face match fails when the face was not clearly enough in view to be compared at all. A plate match fails when the plate was obscured, angled away or dirty. It also fails when a single character is read wrongly, which turns a match into a miss with no warning. So a plate on a watchlist is more brittle than a well-enrolled face. It is also cheaper to set up, because it needs no photographs and no judgment about their quality.

One enrolment, two jobs

A single enrolment does two things that answer very different questions. Going forward, each camera running detection compares the faces it sees against the gallery on its own. There is no handoff between cameras and no order to it, so a camera that has never seen the person before flags them exactly as one that has. A match raises an alert and can start a recording.

Looking back, every recording you already hold can be searched for where that person has been. That second job is where most investigations actually begin. Something has already happened, and the question in the room is where this person has been rather than where they will turn up next. A system that only watches forward cannot answer it at all. What has to have run over a recording before that search finds anything is covered in what analysis can still do with an incident already recorded. It applies whichever route brought you here.

Neither job is worth much without the other. A gallery that only watches forward leaves the question that opened the case unanswered. A search that only looks back tells you nothing the next time the person walks in. Enrolment is one act that buys both, which is the main argument for doing it properly rather than quickly.

One row per recording, not one per sighting

A search for an enrolled subject returns one row for each recording they appear in. That sounds like a formatting detail and it decides whether the answer is usable. Someone who walks in and out of a single camera's view forty times over an afternoon is one row rather than forty. The list stays short enough to read, and the time goes on opening recordings instead of clearing duplicates out of a results page.

It also changes what the result is for. A list of sightings invites counting. A list of recordings invites watching, which is the only thing that settles what actually happened.

Four things that decide whether it works

Each of these rules the method out in some deployment, and it is better to find that out now than during a case. None of them is a fault to be fixed, and all four are worth checking against your own cameras before a case depends on them. The person has to have been detected first. Recognition sits a layer above detection, so a camera not running detection produces nothing to compare against. The person can walk past it and never appear in any result, and no record of that absence exists.

It matches faces. Recognition for people by appearance, for vehicles and for objects is planned rather than available today. An enrolled subject is matched by their face or not at all. Where a case rests on a person seen only from behind, or on a bag, the enrolled route cannot help and cross-camera tracking is what covers it.

The match threshold is set per camera. A camera with poor light or an awkward angle can be tuned on its own, which is useful. It also means the same person may match on one camera and not on the one beside it. Two cameras disagreeing about the same face is a configuration difference rather than a fault.

A weak photograph is flagged but not refused. Every reference image is scored on size, sharpness and brightness as it goes in, so a poor one is visible immediately. It still goes in. A gallery quietly holding unusable images produces quietly poor results, and nobody finds out until a case needed one of them.

Who goes on the list, and who decides

Recognition is turned on deliberately by an administrator in VIDIZMO AI Live Insight rather than running by default, which means somebody in your organization decides to have it at all. The harder question follows immediately. Who may be enrolled, on whose authority, and who reviews the list once it exists. That is a policy your organization writes rather than a setting anyone can hand you, and it belongs in writing before the first case rather than during it.

Two parts of it are easy to overlook. Someone has to be responsible for taking people off the list when the reason they went on has passed. A gallery only ever grows unless removal is a named job. And the list has to be readable by whoever is accountable for it, which is what the tags and the description are actually for.

When someone becomes known partway through

Most cases do not open with a photograph. They open with footage of a person nobody can name, and the name arrives later. That is not a separate path from this one. Every person the cameras pick out already carries a vector embedding computed from their appearance. That is an identifier in a quite different sense from the reference number on a gallery record. Nobody types it in and it points at no file anywhere. Following it across cameras and back through recordings is what cross-camera tracking covers.

When that work establishes who the person is, nothing carries over on its own. The identifier is a value derived from appearance and no picture is kept with it, so there is nothing for a gallery to receive. Enrolling them is a separate decision somebody takes, with reference photographs they supply. From that point they are matched by recognition rather than found by search. So the two routes are one case at two stages, with a decision between them. You find someone you cannot name, you work out who they are, and enrolling them is what makes the cameras aware of the answer.

What to settle first

Settle who may be enrolled and on whose authority, because the first case is a poor time to discover that question has no owner. Then check detection is running on your entrances, exits and boundary points, since recognition cannot report on a camera that was not looking. And gather more than one photograph of anyone you already expect to enrol, taken from different angles rather than the same one twice.

For how a case reaches you in the first place, see how an incident on camera becomes known. For how this sits in a wider camera program, see video intelligence.

TopicsVideo AnalyticsVideo SurveillanceAI Live Insight

You may also like

What Is a Real-Time Crime Center? A Guide for Cities and Counties

What Is a Real-Time Crime Center? A Guide for Cities and Counties

Somewhere in the last two years, someone probably asked your department whether it should have a real-time crime ...

Staffing a Real-Time Crime Center When Software Does the Watching

Staffing a Real-Time Crime Center When Software Does the Watching

Most chiefs who hear a pitch for a real-time crime center ask the same question before any other, which is whether they ...

RTCC, EOC or Situational Awareness Center: What Each Room Is For

RTCC, EOC or Situational Awareness Center: What Each Room Is For

Walk into a real-time crime center, then into a city's emergency operations center, and you will see much the same ...

See all posts

See it on your own content

Tell us what you are trying to solve and we will show you how it works on your infrastructure.