This is a python-based traffic density estimator, works using OpenCV algorithms and functions. Analyses CCTV footage in real time to estimate the density of traffic. Capable of differentiating between idle and moving traffic. Can be used for automatic switching of traffic lights based on traffic density and can even be upgraded to parametrize pedestrian density for higher safety.
It has been implemented in three stages. Each stage either adds up features or increases the efficiency of the system. The stages are as follows:
This stage implements the most basic and necessary functions. Typically the camera gets an arbitrary view of the road/intersection to be monitored and also contains many unnecessary additional objects in the frame. This stage corrects the camera angle and crops out the unwanted objects from the frame.
The camera angle correction is based on Homography. A Homography is a transformation ( a 3×3 matrix ) that maps the points in one image to the corresponding points in the other image. It can be used for perspective correction, panoramic stitching and virtual advertisments. For more info on homography, please check this and this.
These are the video frames at different substages.
Unprocessed initial frame
Perspective corrected
Final post processing frame
____
This stage takes up frames from the input video, processes them using stage 1 functions, and analyses them to estimate the density of traffic. Idle traffic density is referred to as queue density as they would be queuing at the intersection, and moving traffic density is referred to as dynamic density.
Queue density works using background subtraction. Processed empty frame (no traffic, empty road and itnersection) is subtracted from current processed frame to estimate the density of idle traffic.
Dynamic density works on optical flow. It performs optical flow detection across subsequent frames to detect the pixels which moved across frames.
Outputs a graph of both densities with time (or frame number, as required).
Traffic density vs Frame number
In estimating traffic density, accuracy is not the only metric to optimize. Latency, throughput are two other metrics to be optimized. Physically, other important metrics are:
- Temperature of the processor: Temperatures can shoot to 45C and the processor might fry up.
- Energy usage: The system should be efficient in terms of energy usage.
- Security: We obviously dont want hackers to break into the software and cause accidents.
Many of these metrics might conflict with each other. Example, for higher throughput, the system will have to run at higher frequency thereby draining more power and heating up more. Another example, putting security checks against hackers might make the code run slower. This aspect of having multiple metrics to optimize, which conflict with each other, is called trade-off.
In this stage, we do a utility-runtime tradeoff analysis for queue density estimation. We have the following different methods/models/parameters:
-
Method1: Sub-sampling frames - Instead of processing each frame of the 15 fps input video, process every xth frame. Parameter : x = number of frames skipped
-
Method2: Resolution reduction - Reduce resolution of input frames. Lower resoltion frames will be processed higher but will have higher error. Parameter : z = fractional height * fractional width
-
Method3: Spatial multi-threading - Give different parts of the frames to different threads. Paralled would be faster. Parameter : x = number of threads
-
Method4: Temporal multi-threading - Different groups of frames (at different time stamps) can be given to different threads for processing. Parameter : x = number of threads
Please check stage3 folder for detailed description of each method, with outputs, and the pdf report for final conclusions and discussions.