Delivered for a state government wildlife authority in India, through Platform to Platform and Data to Data.
The challenge. Forest staff identified individual tigers by eye from camera footage. The work was continuous, the volume of footage exceeded the number of people available to watch it, and sightings were logged after the fact rather than tracked as they happened.
Context
In 2018 we delivered a wildlife monitoring system for a state government wildlife authority in India, covering a national park, through an enterprise partner. The system identifies individual tigers from live video and tracks their movement on a map.
Individual identification is the requirement, not detection. Knowing a tiger is on camera is of limited use to a forest authority. Knowing which individual it is, and where that individual was yesterday, is the thing.
The problem
The park’s tigers are identified by their stripe patterns, which are individual and stable, much like a fingerprint. Rangers who know the animals can do this by eye. The constraint is arithmetic: camera feeds run continuously, the number of hours of footage produced each day is larger than the number of hours of attention available, and the identification happens after the footage is reviewed rather than while the animal is in frame.
The consequences are practical. Movement patterns get reconstructed retrospectively from sighting logs. Territory and range questions are answered weeks late. And the expertise sits with a small number of people, which makes it a staffing dependency rather than an institutional capability.
Why it is hard
A stripe pattern is not a face. Off-the-shelf recognition assumes canonical views. A tiger presents at whatever angle it happens to be walking, partially occluded by vegetation, at whatever light the time of day provides, often in motion and often at distance. The identifying region may be a flank visible for two seconds.
The class set is small, open and grows. There are not thousands of individuals to learn, there are tens. New individuals appear. A classifier with a fixed output layer is the wrong shape for a population that changes.
Being wrong quietly is worse than being unsure. A confident misidentification corrupts the movement record for two animals at once, and it does so in a dataset that the authority will later use to make decisions. The system needs an operator in the loop who can disagree with it.
The deployment environment is rugged. Remote cameras, intermittent connectivity, and no data centre nearby.
What we built
A stripe-pattern recognition model. Bootstrapped on a pre-trained image recognition base and retrained on more than 20,000 labelled tiger images specifically for stripe-pattern discrimination. Feed-forward networks handle incremental retraining, so new individuals and new imagery extend the model rather than requiring a rebuild.
Frame extraction and processing off continuous video. Java microservices handle ingestion, frame extraction, processing and the retraining pipeline, with OpenCV and FFmpeg doing the video work. The pipeline runs against live feeds, not uploaded batches.
An operator feedback loop that actually retrains. Rangers and operators validate or correct each identification in a dashboard. Those corrections are the training input for the next retraining pass. This is the part that makes the accuracy figure durable: the system improves from the same activity that validates it, so the labelling effort is not a separate project that gets deprioritised.
GIS path tracking. Sightings are plotted on an interactive Mapbox-based map as movement paths per individual, with historical tracking and trend reporting. The front end is ReactJS with Chart.js for the analytics views.
Stack: TensorFlow with a pre-trained vision base and custom retraining, OpenCV and FFmpeg for image and video processing, Java and Spring Boot behind REST APIs, ReactJS with Mapbox and Chart.js on the front, Docker for deployment.
Results
96% identification accuracy on individual tiger identification.
Surveillance workload fell by around 70%. Staff moved from watching footage to adjudicating candidate identifications, which is a different and much smaller job.
Identification became continuous rather than retrospective. Movement paths build as sightings occur.
The model improves from operator use. Each correction is training data, so accuracy is maintained by the same people who consume the output.
What we would do differently
We would treat the operator dashboard as the primary product from day one. It was built as the validation interface for the model, and it turned out to be where the institutional value accumulated — the corrected identification record is more useful to the authority than the model that proposed it. Designing the record first would have produced a better dataset and a cleaner retraining path.
We would also separate detection from identification more explicitly. Collapsing “is there a tiger” and “which tiger” into one model made failures harder to attribute. Two stages cost more compute and are much easier to reason about when accuracy drops on a particular camera or season.
Where this transfers
Identifying a specific individual from partial, uncontrolled visual data and maintaining accuracy through an operator feedback loop is the same problem shape as municipal infrastructure inspection from vehicle or CCTV footage, PPE and safety compliance monitoring on industrial sites, and traffic enforcement from existing camera estates. In each case the value is not the detection, it is the reviewed record that accumulates behind it.