OBJECT DETECTION AND IDENTIFICATION USING YOLO

ABSTRACT

Over the past two decades, computer vision has received a great deal of
coverage. Visual object tracking is one of the most important areas of computer
vision. Tracking objects is the process of tracking over time a moving object (or
several objects). The purpose of visual object tracking in consecutive video
frames is to detect or connect target objects. In this Project, we present analysis
of tracking-by-detection approach which include detection and tracking by
YOLO algorithm. This Project has information about YOLO coco image dataset
being trained more classes using YOLO and this model is being used in videos
for tracking. Recognizing a vehicle or pedestrian in an ongoing video is helpful
for traffic analysis. The goal of this Project is for analysis and detection of the
objects in stored video. Object detection systems always construct a model for an
object class from a set of training examples. In the case of a fixed rigid object in
an image, only one example may be needed, but more generally multiple training
examples are necessary to capture certain aspects of class variability.
 CHAPTER-1

INTRODUCTION
1.1 Objective
The aim of object detection is to detect all instances of objects from a known class, such
as people, cars or faces in an image. Generally, only a small number of instances of the object
are present in the image, but there is a very large number of possible locations and scales at
which they can occur and that need to somehow be explored. Each detection of the image is
reported with some form of pose information. This is as simple as the location of the object, a
location and scale, or the extent of the object defined in terms of a bounding box. In some other
situations, the pose information is more detailed and contains the parameters of a linear or non-
linear transformation. Object detection systems always construct a model for an object class
from a set of training examples. In the case of a fixed rigid object in an image, only one example
may be needed, but more generally multiple training examples are necessary to capture certain
aspects of class variability.
Object detection is an important task, yet challenging vision task. It is a critical part of
many applications such as image search, image auto-annotation and scene understanding,
object tracking. Moving object tracking of video image sequences was one of the most
important subjects in computer vision. It had already been applied in many computer vision
fields, such as smart video surveillance (Arun Hampapur 2005), artificial intelligence, military
guidance, safety detection and robot navigation, medical and biological application. In recent
years, a number of successful single-object tracking system appeared, but in the presence of
several objects, object detection becomes difficult and when objects are fully or partially
occluded, they are obtruded from the human vision which further increases the problem of
detection. Decreasing illumination and acquisition angle. The proposed MLP based object
tracking system is made robust by an optimum selection of unique features and also by
implementing the Adobos strong classification method.
The YOLO (You Only Look Once) algorithm using Convolutional Neural Network is
used for the detection purpose. It is a Deep Neural Network concept from Artificial Neural
Network. Artificial Neural Network is inspired by the biological concept of Nervous System
where the neurons are the nodes that form the network. Similarly, in Artificial Neural Network
perceptron’s act like the nodes in the network. Artificial Neural Network has three layers that
are, Input Layer, Hidden Layer and the output Layer. Deep Learning is the part of the Artificial
Neural Network that has multiple Hidden Layer that can be used for the Feature Extraction and
Classification purposes. Convolutional Neural Network (CNN) is the part of Deep Learning
that is used in analysis of visual imagery. It has four different kinds of layers, they are,
Convolutional Layer, Pooling Layer, Activation Layer and Fully Connected Layer.
Convolution Layer uses filter and strides to obtain the Feature Maps. These Feature Maps are
the matrix that is obtained after the Convolution Layer. It can be simplified using ReLU
(Rectified Linear Unit) that maps negative values to 0.
 CHAPTER-2
Literature Review

2.1 Object Detection With Sliding Window in Images Including Multiple Similar Objects

Authors:

Jinsu Lee, Junseong Bang, and Seong Yang

Abstract

Given an image containing an object of interest, the object can be detected by comparing the
feature points in the given image with those in a reference object image. In a case where the
given image contains a large number of similar objects, the object of interest is difficult to be
detected. It is because the feature points in the given image are concentrated in some regions
where each region has a drastic change in the intensity of points. One of the methods to
overcome the problem of the feature concentrating is to increase the limitation in the number
of feature points to be used for the detection. However, this causes more computational load.
Alternatively, the resolution of the image can be lowered, but this method decreases the
accuracy of detection. In this paper, in order to detect the object of interest in an image with
multiple similar objects, a sliding window for feature matching is used. The sliding window is
optimized in size for better performance of the object detection. As a practical example, a
service that visualizes the location of a desired book in a library is considered. The image for
feature matching is obtained from high-resolution CCTVs which are connected to a cloud
server that has databases of book title images. This service can be extended to visualize the
location of the object to the users, using augmented reality (AR) technology on a mobile
platform of a smart phone or smart glasses. The presented method for this service is
experimentally evaluated.

Keywords: Object Detection, Bounding Box, Convolutional Neural Network.

2.2 Fast Detection of Multiple Objects in Traffic Scenes With a Common Detection
Framework

Authors: Qichang Hu, Sakrapee Paisitkriangkrai, Chunhua Shen, Anton van den Hengel, and
Fatih Porikli

Abstract

Traffic scene perception (TSP) aims to extract accurate real-time on-road environment
information, which involves three phases: detection of objects of interest, recognition of
detected objects, and tracking of objects in motion. Since recognition and tracking often rely
on the results from detection, the ability to detect objects of interest effectively plays a crucial
role in TSP. In this paper, we focus on three important classes of objects: traffic signs, cars,
and cyclists. We propose to detect all the three important objects in a single learning-based
detection framework. The proposed framework consists of a dense feature extractor and
detectors of three important classes. Once the dense features have been extracted, these features
are shared with all detectors. The advantage of using one common framework is that the
detection speed is much faster, since all dense features need only to be evaluated once in the
testing phase. In contrast, most previous works have designed specific detectors using different
features for each of these three classes. To enhance the feature robustness to noises and image
deformations, we introduce spatially pooled features as a part of aggregated channel features.
In order to further improve the generalization performance, we propose an object
subcategorization method as a means of capturing the intraclass variation of objects. We
experimentally demonstrate the effectiveness and efficiency of the proposed framework in
three detection applications: traffic sign detection, car detection, and cyclist detection. The
proposed framework achieves the competitive performance with state-of-the-art approaches on
several benchmark data sets.

Keywords: Traffic scene perception, traffic sign detection, car detection, cyclist detection,
object subcategorization.
2.3 Object Detection using Machine Learning Technique

Authors: Praahas Amin, Anushree B. S., Bhavana B. Shetty, Kavya K., Likitha Shetty.

Abstract

The main aim of this project is to build a system that detects objects from the image or a stream
of images given to the system in the form of previously recorded video or the real time input
from the camera. Bounding boxes will be drawn around the objects that are being detected by
the system. The system will also classify the object to the classes the object belongs. Python
Programming and a Machine Learning Technique named YOLO (You Only Look Once)
algorithm using Convolutional Neural Network is used for the Object Detection. The YOLO
(You Only Look Once) algorithm using Convolutional Neural Network is used for the detection
purpose. It is a Deep Neural Network concept from Artificial Neural Network. Artificial Neural
Network is inspired by the biological concept of Nervous System where the neurons are the
nodes that form the network. Similarly, in Artificial Neural Network perceptrons act like the
nodes in the network. Artificial Neural Network has three layers that are, Input Layer, Hidden
Layer and the output Layer. Deep Learning is the part of the Artificial Neural Network that has
multiple Hidden Layer that can be used for the Feature Extraction and Classification purposes

Key Words: Machine Learning, Object Detection, YOLO, Bounding Box, Convolutional
Neural Network.
 CHAPTER-3
SYSTEM ANALYSIS
3.1 EXISTING SYSTEM
A few years ago, the creation of the software and hardware image processing systems
was mainly limited to the development of the user interface, which most of the programmers
of each firm were engaged in. The situation has been significantly changed with the advent of
the Windows operating system when the majority of the developers switched to solving the
problems of image processing itself.

3.1.1PROBLEMS
• Difficult in recognizing faces, car numbers, road signs, analyzing remote and
medical images, etc
• Object detection is difficult in the basis of Multiple images.
• object detection in video is very difficult.

3.2 PROPOSED SYSTEM

Each image will be identified with its object names. The network does not look at the
complete image. Instead, parts of the image which has high probabilities of containing the
object. YOLO or You Only Look Once is an object detection algorithm much is different from
the region-based algorithms which seen above. In YOLO a single convolutional network
predicts the bounding boxes and the class probabilities for these boxes.

3.2.1 Advantages:
• Each detection of the image is reported with some form of pose information.
• The pose information is more detailed and contains the parameters of a linear
or non-linear transformation.
• object detection in video is accurate and multiple images can be identified
easily.
 CHAPTER-4
SYSTEM SPECIFICATION

4.1 Hardware Requirement

Processor 3 GHz above

RAM 4 Gb above
Disk Space (32bit) 1 Gb above

4.2 Software Requirement

• Python 3.7.9
• OpenCV
• Windows 7 or above
 CHAPTER-5

SYSTEM OVERVIEW

5.1 SYSTEM MODULES

o Input Video
o Image Classification
o Object Localization
o Object Detection

5.1.1 Input video

A recorded video will be added. Where video consist of collection of images. An image
which consists of one or more objects, such as a photograph.

5.1.2 Image Classification

This is done by Predict the type or class of an object in an image. image classification
is simply straight forward, but the differences between object localization and object detection
can be confusing, especially when all three tasks may be just as equally referred to as object
recognition.

5.1.3 Object Localization

This is done through, Locate the presence of objects in an image and indicate their
location with a bounding box. whereas object localization involves drawing a bounding box
around one or more objects in an image.

5.1.4 Object Detection

This is done through, Locate the presence of objects with a bounding box and types or
classes of the located objects in an image. Object detection is always more challenging and
combines these two tasks and draws a bounding box around each object of interest in the image
and assigns them a class label.
5.2 Algorthim Description

All the previous object detection algorithms have used regions to localize the object
within the image. The network does not look at the complete image. Instead, parts of the image
which has high probabilities of containing the object. YOLO or You Only Look Once is an
object detection algorithm much is different from the region based algorithms which seen
above. In YOLO a single convolutional network predicts the bounding boxes and the class
probabilities for these boxes.

5.2.1 Implementation

YOLO works by taking an image and split it into an SxS grid, within each of the grid
we take m bounding boxes. For each of the bounding box, the network gives an output a class
probability and offset values for the bounding box. The bounding boxes have the class
probability above a threshold value is selected and used to locate the object within the image.
YOLO is orders of magnitude faster(45 frames per second) than any other object detection
algorithms. The limitation of YOLO algorithm is that it struggles with the small objects within
the image, for example, it might have difficulties in identifying a flock of birds. This is due to
the spatial constraints of the algorithm.
YOLOv3 is extremely fast and accurate. In mAP measured at .5 IOU YOLOv3 is on
par with Focal Loss but about 4x faster. Moreover, you can easily tradeoff between speed and
accuracy simply by changing the size of the model, no retraining required.
5.2.1.1 Code:

YOLO from disk...")

net = cv2.dnn.readNetFromDarknet(configPath, weightsPath)
ln = net.getLayerNames()
ln = [ln[i[0] - 1] for i in net.getUnconnectedOutLayers()]

# initialize the video stream, pointer to output video file, and

# frame dimensions
vs = cv2.VideoCapture(args["input"])
writer = None
(W, H) = (None, None)

# try to determine the total number of frames in the video file

try:
prop = cv2.cv.CV_CAP_PROP_FRAME_COUNT if imutils.is_cv2() \
else cv2.CAP_PROP_FRAME_COUNT
total = int(vs.get(prop))
print("[INFO] {} total frames in video".format(total))

# an error occurred while trying to determine the total

# number of frames in the video file
except:
print("[INFO] could not determine # of frames in video")
print("[INFO] no approx. completion time can be provided")
total = -1

# loop over frames from the video file stream

while True:
# read the next frame from the file
(grabbed, frame) = vs.read()
# if the frame was not grabbed, then we have reached the end
# of the stream
if not grabbed:
break

# if the frame dimensions are empty, grab them

if W is None or H is None:
(H, W) = frame.shape[:2]

# construct a blob from the input frame and then perform a forward
# pass of the YOLO object detector, giving us our bounding boxes
# and associated probabilities
blob = cv2.dnn.blobFromImage(frame, 1 / 255.0, (416, 416),
swapRB=True, crop=False)
net.setInput(blob)
start = time.time()
layerOutputs = net.forward(ln)
end = time.time()

# initialize our lists of detected bounding boxes, confidences,

# and class IDs, respectively
boxes = []
confidences = []
classIDs = []

# loop over each of the layer outputs

for output in layerOutputs:
# loop over each of the detections
for detection in output:
# extract the class ID and confidence (i.e., probability)
# of the current object detection
scores = detection[5:]
classID = np.argmax(scores)
confidence = scores[classID]
 # filter out weak predictions by ensuring the detected
# probability is greater than the minimum probability
if confidence > args["confidence"]:
# scale the bounding box coordinates back relative to
# the size of the image, keeping in mind that YOLO
# actually returns the center (x, y)-coordinates of
# the bounding box followed by the boxes' width and
# height
box = detection[0:4] * np.array([W, H, W, H])
(centerX, centerY, width, height) = box.astype("int")

# use the center (x, y)-coordinates to derive the top

# and and left corner of the bounding box
x = int(centerX - (width / 2))
y = int(centerY - (height / 2))

# update our list of bounding box coordinates,

# confidences, and class IDs
boxes.append([x, y, int(width), int(height)])
confidences.append(float(confidence))
classIDs.append(classID)

# apply non-maxima suppression to suppress weak, overlapping

# bounding boxes
idxs = cv2.dnn.NMSBoxes(boxes, confidences, args["confidence"],
args["threshold"])

# ensure at least one detection exists

if len(idxs) > 0:
# loop over the indexes we are keeping
for i in idxs.flatten():
# extract the bounding box coordinates
(x, y) = (boxes[i][0], boxes[i][1])
 (w, h) = (boxes[i][2], boxes[i][3])

# draw a bounding box rectangle and label on the frame

color = [int(c) for c in COLORS[classIDs[i]]]
cv2.rectangle(frame, (x, y), (x + w, y + h), color, 2)
text = "{}: {:.4f}".format(LABELS[classIDs[i]],
confidences[i])
cv2.putText(frame, text, (x, y - 5),
cv2.FONT_HERSHEY_SIMPLEX, 0.5, color, 2)

# check if the video writer is None

if writer is None:
# initialize our video writer
fourcc = cv2.VideoWriter_fourcc(*"MJPG")
writer = cv2.VideoWriter(args["output"], fourcc, 30,
(frame.shape[1], frame.shape[0]), True)

# some information on processing single frame

if total > 0:
elap = (end - start)
print("[INFO] single frame took {:.4f} seconds".format(elap))
print("[INFO] estimated total time to finish: {:.4f}".format(
elap * total))

# write the output frame to disk

writer.write(frame)

# release the file pointers

print("[INFO] cleaning up...")
writer.release()
vs.release()
5.3 Software Description

5.3.1Python
Flexible and powerful, Python was originally developed in the late 1980s at the
National Research Institute for Mathematics and Computer Science by Guido van Rossum as
a successor to the ABC language. Since its introduction, Python has grown in popularity thanks
to what is seen as a clear and expressive syntax developed with a focus on ensuring that code
is readable. Python is a high-level language. This means that Python code is written in largely
recognizable English, providing the Pi with commands in a manner that is quick to learn and
easy to follow. This is in marked contrast to low-level languages, like assembler, which are
closer to how the computer “thinks” but almost impossible for a human to follow without
experience. The high-level nature and clear syntax of Python make it a valuable tool for anyone
who wants to learn to program. It is also the language that is recommended by the Raspberry
Pi Foundation for those looking to progress from the simple Scratch.

Example : Hello World

print “Hello, World!”

The final program should look like this:
#!/usr/bin/env python
print “Hello, World!”
If you’re creating the example program in IDLE rather than a plain text editor, you’ll
notice that the text is multi colored, (where colours are represented as differing shades of grey
in the print edition). This is a feature known as syntax highlighting, and is a feature of IDEs
and the more-advanced text editing tools. Syntax highlighting changes the colour of sections
of the text according to their function, in order to make the program easier to understand at a
glance. It also makes it easy to spot so-called syntax errors caused by forgetting to put an end-
quote in a print command or forgetting to comment out a remark. For this short example, syntax
highlighting isn’t necessary—but in larger programs, it can be an invaluable tool for finding
errors. Syntax highlighting in IDLE.

Running helloworld.py in IDLE

If you created the helloworld.py program in a text editor, you’ll need to open a terminal
window from the Accessories menu on the desktop. If you saved the file anywhere except your
home directory, you’ll also have to use the cd command to change to that directory (see Chapter
2, “Linux System Administration”). Once you’re in the right directory, you can run your
program by typing the following: python helloworld.py This tells the operating system to run
Python and then load the helloworld.py file for execution. Unlike the Python shell in IDLE,
Python will quit when it reaches the end of the file and return you to the terminal. The result,
however, is the same: the message Hello, World! is printed to the standard output .

Running helloworld.py at the terminal

Making Python Programs Executable Normally, the only way to run a Python
program is to tell the Python software to open the file. With the shebang line at the top of the
file, however, it’s possible to execute the file directly without having to call Python first. This
can be a useful way of making your own tools that can be executed at the terminal: once copied
into a location in the system’s $PATH environment variable, the Python program can be called
simply by typing its name. First, you need to tell Linux that the Python file should be marked
as executable—an attribute that means the file is a program. To protect the system from
malware being downloaded from the Internet this attribute isn’t automatically set, since only
files that are marked as executable will run. To make the helloworld.py file executable, use the
chmod command (described in detail in Chapter 2, “Linux System Administration”) by typing
the following: chmod +x helloworld.py Now try running the program directly by typing the
following:
./helloworld.py

Despite the fact that you didn’t call the Python program, the helloworld.py program
should run just the same as if you’d typed python helloworld.py. The program can only be run
by calling it with its full location—/home/pi/helloworld.py—or from the current directory by
using ./ as the location. To make the file accessible in the same way as any other terminal
command, it needs to be copied to /usr/local/bin with the following command: sudo cp
helloworld.py /usr/local/bin/
The sudo prefix is required because, for security reasons, non-privileged users cannot
write to the /usr/local/bin directory. With the helloworld.py file located in /usr/local/bin, which
is included in the $PATH variable, it can be executed from any directory by simply typing its
name. Try changing to a different directory, and then run the program by typing the following:
helloworld.py To make your custom-made programs seem more like native utilities, you can
rename them to remove the .py file extension. To change the helloworld.py program in this
way, just type the following line at the terminal as a single line: sudo mv
/usr/local/bin/helloworld.py
/usr/local/bin/helloworld Once renamed, the program can be run simply by typing helloworld
at the terminal or console.
 CHAPTER-6
SYSTEM DESIGN

6.1 OPENCV

OpenCV is a cross-platform library using which we can develop real-time computer

vision applications. It mainly focuses on image processing, video capture and analysis
including features like face detection and object detection.

Features of OpenCV Library

Using OpenCV library, you can −

• Read and write images

• Capture and save videos
• Process images (filter, transform)
• Perform feature detection
• Detect specific objects such as faces, eyes, cars, in the videos or images.
• Analyze the video, i.e., estimate the motion in it, subtract the background, and track
objects in it.

OpenCV was originally developed in C++. In addition to it, Python and Java bindings were
provided. OpenCV runs on various Operating Systems such as windows, Linux, OSx,
FreeBSD, Net BSD, Open BSD, etc.

This tutorial explains the concepts of OpenCV with examples using Java bindings.

OpenCV Library Modules

Following are the main library modules of the OpenCV library.

Core Functionality

This module covers the basic data structures such as Scalar, Point, Range, etc., that are used to
build OpenCV applications. In addition to these, it also includes the multidimensional array
Mat, which is used to store the images. In the Java library of OpenCV, this module is included
as a package with the name org.opencv.core.

Image Processing

This module covers various image processing operations such as image filtering, geometrical
image transformations, color space conversion, histograms, etc. In the Java library of OpenCV,
this module is included as a package with the name org.opencv.imgproc.

Video

This module covers the video analysis concepts such as motion estimation, background
subtraction, and object tracking. In the Java library of OpenCV, this module is included as a
package with the name org.opencv.video.

Video I/O

This module explains the video capturing and video codecs using OpenCV library. In the Java
library of OpenCV, this module is included as a package with the name org.opencv.videoio.

calib3d

This module includes algorithms regarding basic multiple-view geometry algorithms, single
and stereo camera calibration, object pose estimation, stereo correspondence and elements of
3D reconstruction. In the Java library of OpenCV, this module is included as a package with
the name org.opencv.calib3d.

features2d

This module includes the concepts of feature detection and description. In the Java library of
OpenCV, this module is included as a package with the name org.opencv.features2d.

Objdetect

This module includes the detection of objects and instances of the predefined classes such as
faces, eyes, mugs, people, cars, etc. In the Java library of OpenCV, this module is included as
a package with the name org.opencv.objdetect.
6.2 ARCHITECTURE DIAGRAM
6.3 UML Diagram

• Structure Diagrams

o Class Diagram

o Component Diagram

o Deployment Diagram

o Object Diagram

o Package Diagram

• Behavioural Diagrams

o Use Case Diagram

o Activity Diagram

o State Machine Diagram

o Sequence Diagram

o Timing Diagram
6.3.1Usecase Diagram

Input Video

Input identification

Image CNN

Image classification Machine

Client

YOLO Image

Object
Localization

Object Detection

Fig: 6.3.1.1 system use case diagram

Description:
Use case diagrams gives a graphic overview of the actors involved in a system, different
functions needed by those actors and how these different functions are interacted. Here the
sender and receiver are the actors and select video, select file, encryption key, decrypt data,
extract data and view data are the functions
6.3.2 CLASS DIAGRAM

User
Input Video Application
Request
Images
Response
Input()
Open applicatio()

Machjine
CNN
YOLO
Open application
Image Detect()

Fig: 6.3.1.2 Class diagram

Description
It is the main building block of any object oriented solution. It shows the classes in a
system, attributes and operations of each class and the relationship between each class.

A class has three parts, name at the top, attributes in the middle and operations or
methods at the bottom. In large systems with many related classes, classes are grouped together
to create class diagrams. Different relationships between classes are shown by different types
of arrows.

Here sender, embed data, receiver, encrypt and decrypt are the classes, each class
contains its own attribute and functions, they are related by arrows.
6.3.3 SEQUENCE DIAGRAM

user application Machine YOLO

1.Image Input

response

3.Image classification

4.Image Localization

5.imag detection

Fig: 6.3.1.3 sequence diagram

Description:
Sequence diagrams in UML shows how object interact with each other and the order
those interactions occur. It’s important to note that they show the interactions for a particular
scenario. The processes are represented vertically and interactions are show as arrows.

Here sender, receiver, embedding data and room are objects they interact each other.
The arrow shows interaction like send cover video and data, reserving room etc.
6.3.4 ACTIVITY DIAGRAM:-

User

Input Video

Image
Classification

Image
Machine
Localization

Image
identification

Image
shape
identify

Image
Detection

Fig: 6.3.1.4 Activity diagram

Description:
Activity diagrams represent workflows in an graphical way. They can be used to
describe business workflow or the operational workflow of any component in a system

✓ rounded rectangles represent actions;

✓ diamonds represent decisions;
✓ bars represent the start (split) or end (join) of concurrent activities;
✓ a black circle represents the start (initial state) of the workflow;
✓ an encircled black circle represents the end (final state).
 CHAPTER-7

SOFTWARE TESTING
7 .1 TESTING

The various levels of testing are

1. White Box Testing

2. Black Box Testing
3. Unit Testing
4. Functional Testing
5. Performance Testing
6. Integration Testing
7. Objective
8. Integration Testing
9. Validation Testing
10. System Testing
11. Structure Testing
12. Output Testing
13. User Acceptance Testing

7.1.1 WHITE BOX TESTING

White-box testing (also known as clear box testing, glass box testing, transparent box
testing, and structural testing) is a method of testing software that tests internal structures or
workings of an application, as opposed to its functionality (i.e. black-box testing). In white-
box testing an internal perspective of the system, as well as programming skills, are used to
design test cases. The tester chooses inputs to exercise paths through the code and determine
the appropriate outputs. This is analogous to testing nodes in a circuit, e.g. in-circuit
testing (ICT).

While white-box testing can be applied at the unit, integration and system levels of
the software testing process, it is usually done at the unit level. It can test paths within a unit,
paths between units during integration, and between subsystems during a system–level test.
Though this method of test design can uncover many errors or problems, it might not detect
unimplemented parts of the specification or missing requirements.
White-box test design techniques include:

• Control flow testing

• Data flow testing
• Branch testing
• Path testing
• Statement coverage
• Decision coverage

White-box testing is a method of testing the application at the level of the source code.
The test cases are derived through the use of the design techniques mentioned above: control
flow testing, data flow testing, branch testing, path testing, statement coverage and decision
coverage as well as modified condition/decision coverage. White-box testing is the use of these
techniques as guidelines to create an error free environment by examining any fragile code.

These White-box testing techniques are the building blocks of white-box testing, whose
essence is the careful testing of the application at the source code level to prevent any hidden
errors later on. These different techniques exercise every visible path of the source code to
minimize errors and create an error-free environment. The whole point of white-box testing is
the ability to know which line of the code is being executed and being able to identify what the
correct output should be.

Levels

1. Unit testing. White-box testing is done during unit testing to ensure that the code is
working as intended, before any integration happens with previously tested code.
White-box testing during unit testing catches any defects early on and aids in any
defects that happen later on after the code is integrated with the rest of the application
and therefore prevents any type of errors later on.

2. Integration testing. White-box testing at this level are written to test the interactions of
each interface with each other. The Unit level testing made sure that each code was
tested and working accordingly in an isolated environment and integration examines
the correctness of the behaviour in an open environment through the use of white-box
testing for any interactions of interfaces that are known to the programmer.
 3. Regression testing. White-box testing during regression testing is the use of recycled
white-box test cases at the unit and integration testing levels.

White-box testing's basic procedures involve the understanding of the source code that you
are testing at a deep level to be able to test them. The programmer must have a deep
understanding of the application to know what kinds of test cases to create so that every visible
path is exercised for testing. Once the source code is understood then the source code can be
analysed for test cases to be created. These are the three basic steps that white-box testing takes
in order to create test cases:

1. Input, involves different types of requirements, functional specifications, detailed

designing of documents, proper source code, security specifications. This is the
preparation stage of white-box testing to layout all of the basic information.
2. Processing Unit, involves performing risk analysis to guide whole testing process,
proper test plan, execute test cases and communicate results. This is the phase of
building test cases to make sure they thoroughly test the application the given results
are recorded accordingly.
3. Output, prepare final report that encompasses all of the above preparations and results.

7.1.2 Black Box Testing

Black-box testing is a method of software testing that examines the functionality of an

application (e.g. what the software does) without peering into its internal structures or workings
(see white-box testing). This method of test can be applied to virtually every level of software
testing: unit, integration, system and acceptance. It typically comprises most if not all higher-
level testing, but can also dominate unit testing as well

Test procedures

Specific knowledge of the application's code/internal structure and programming

knowledge in general is not required. The tester is aware of what the software is supposed to
do but is not aware of how it does it. For instance, the tester is aware that a particular input
returns a certain, invariable output but is not aware of how the software produces the output in
the first place.
Test cases

Test cases are built around specifications and requirements, i.e., what the application is
supposed to do. Test cases are generally derived from external descriptions of the software,
including specifications, requirements and design parameters. Although the tests used are
primarily functional in nature, non-functional tests may also be used. The test designer selects
both valid and invalid inputs and determines the correct output without any knowledge of the
test object's internal structure.

Test design techniques

Typical black-box test design techniques include:

• Decision table testing

• All-pairs testing
• State transition tables
• Equivalence partitioning
• Boundary value analysis

7.1.3 Unit testing

In computer programming, unit testing is a method by which individual units of source

code, sets of one or more computer program modules together with associated control data,
usage procedures, and operating procedures are tested to determine if they are fit for use.
Intuitively, one can view a unit as the smallest testable part of an application. In procedural
programming, a unit could be an entire module, but is more commonly an individual function
or procedure. In object-oriented programming, a unit is often an entire interface, such as a class,
but could be an individual method. Unit tests are created by programmers or occasionally
by white box testers during the development process.

Ideally, each test case is independent from the others. Substitutes such as method
stubs, mock objects, fakes, and test harnesses can be used to assist testing a module in isolation.
Unit tests are typically written and run by software developers to ensure that code meets its
design and behaves as intended. Its implementation can vary from being very manual (pencil
and paper)to being formalized as part of build automation.
 Testing will not catch every error in the program, since it cannot evaluate every
execution path in any but the most trivial programs. The same is true for unit testing.
Additionally, unit testing by definition only tests the functionality of the units themselves.
Therefore, it will not catch integration errors or broader system-level errors (such as functions
performed across multiple units, or non-functional test areas such as performance).

Unit testing should be done in conjunction with other software testing activities, as they
can only show the presence or absence of particular errors; they cannot prove a complete
absence of errors. In order to guarantee correct behaviour for every execution path and every
possible input, and ensure the absence of errors, other techniques are required, namely the
application of formal methods to proving that a software component has no unexpected
behaviour.

Software testing is a combinatorial problem. For example, every Boolean decision statement
requires at least two tests: one with an outcome of "true" and one with an outcome of "false".
As a result, for every line of code written, programmers often need 3 to 5 lines of test code.

This obviously takes time and its investment may not be worth the effort. There are
also many problems that cannot easily be tested at all – for example those that
are nondeterministic or involve multiple threads. In addition, code for a unit test is likely to be
at least as buggy as the code it is testing. Fred Brooks in The Mythical Man-
Month quotes: never take two chronometers to sea. Always take one or three. Meaning, if
two chronometers contradict, how do you know which one is correct?

Another challenge related to writing the unit tests is the difficulty of setting up realistic
and useful tests. It is necessary to create relevant initial conditions so the part of the application
being tested behaves like part of the complete system. If these initial conditions are not set
correctly, the test will not be exercising the code in a realistic context, which diminishes the
value and accuracy of unit test results.

To obtain the intended benefits from unit testing, rigorous discipline is needed
throughout the software development process. It is essential to keep careful records not only of
the tests that have been performed, but also of all changes that have been made to the source
code of this or any other unit in the software. Use of a version control system is essential. If a
later version of the unit fails a particular test that it had previously passed, the version-control
software can provide a list of the source code changes (if any) that have been applied to the
unit since that time.
 It is also essential to implement a sustainable process for ensuring that test case failures
are reviewed daily and addressed immediately if such a process is not implemented and
ingrained into the team's workflow, the application will evolve out of sync with the unit test
suite, increasing false positives and reducing the effectiveness of the test suite.

Unit testing embedded system software presents a unique challenge: Since the software
is being developed on a different platform than the one it will eventually run on, you cannot
readily run a test program in the actual deployment environment, as is possible with desktop
programs.

7.1.4 Functional testing

Functional testing is a quality assurance (QA) process and a type of black box
testing that bases its test cases on the specifications of the software component under test.
Functions are tested by feeding them input and examining the output, and internal program
structure is rarely considered (not like in white-box testing). Functional Testing usually
describes what the system does.

Functional testing differs from system testing in that functional testing "verifies a program by
checking it against ... design document(s) or specification(s)", while system testing "validate a
program by checking it against the published user or system requirements" (Kane, Falk,
Nguyen 1999, p. 52).

Functional testing typically involves five steps .The identification of functions that the
software is expected to perform

1. The creation of input data based on the function's specifications

2. The determination of output based on the function's specifications
3. The execution of the test case
4. The comparison of actual and expected outputs

7.1.5 Performance testing

In software engineering, performance testing is in general testing performed to

determine how a system performs in terms of responsiveness and stability under a particular
workload. It can also serve to investigate, measure, validate or verify other quality attributes of
the system, such as scalability, reliability and resource usage.
 Performance testing is a subset of performance engineering, an emerging computer
science practice which strives to build performance into the implementation, design and
architecture of a system.

Testing types

Load testing

Load testing is the simplest form of performance testing. A load test is usually
conducted to understand the behaviour of the system under a specific expected load. This load
can be the expected concurrent number of users on the application performing a specific
number of transactions within the set duration. This test will give out the response times of all
the important business critical transactions. If the database, application server, etc. are also
monitored, then this simple test can itself point towards bottlenecks in the application software.

Stress testing

Stress testing is normally used to understand the upper limits of capacity within the
system. This kind of test is done to determine the system's robustness in terms of extreme load
and helps application administrators to determine if the system will perform sufficiently if the
current load goes well above the expected maximum.

Soak testing

Soak testing, also known as endurance testing, is usually done to determine if the
system can sustain the continuous expected load. During soak tests, memory utilization is
monitored to detect potential leaks. Also important, but often overlooked is performance
degradation. That is, to ensure that the throughput and/or response times after some long period
of sustained activity are as good as or better than at the beginning of the test. It essentially
involves applying a significant load to a system for an extended, significant period of time. The
goal is to discover how the system behaves under sustained use.

Spike testing

Spike testing is done by suddenly increasing the number of or load generated by, users
by a very large amount and observing the behaviour of the system. The goal is to determine
whether performance will suffer, the system will fail, or it will be able to handle dramatic
changes in load.
Configuration testing

Rather than testing for performance from the perspective of load, tests are created to
determine the effects of configuration changes to the system's components on the system's
performance and behaviour. A common example would be experimenting with different
methods of load-balancing.

Isolation testing

Isolation testing is not unique to performance testing but involves repeating a test
execution that resulted in a system problem. Often used to isolate and confirm the fault domain.

Integration testing

Integration testing (sometimes called integration and testing, abbreviated I&T) is

the phase in software testing in which individual software modules are combined and tested as
a group. It occurs after unit testing and before validation testing. Integration testing takes as its
input modules that have been unit tested, groups them in larger aggregates, applies tests
defined in an integration test plan to those aggregates, and delivers as its output the integrated
system ready for system testing.

Purpose

The purpose of integration testing is to verify functional, performance, and

reliability requirements placed on major design items. These "design items", i.e. assemblages
(or groups of units), are exercised through their interfaces using black box testing, success and
error cases being simulated via appropriate parameter and data inputs. Simulated usage of
shared data areas and inter-process communication is tested and individual subsystems are
exercised through their input interface.

Test cases are constructed to test whether all the components within assemblages
interact correctly, for example across procedure calls or process activations, and this is done
after testing individual modules, i.e. unit testing. The overall idea is a "building block"
approach, in which verified assemblages are added to a verified base which is then used to
support the integration testing of further assemblages.

Some different types of integration testing are big bang, top-down, and bottom-up.
Other Integration Patterns are: Collaboration Integration, Backbone Integration, Layer
Integration, Client/Server Integration, Distributed Services Integration and High-frequency
Integration.
Big Bang

In this approach, all or most of the developed modules are coupled together to form a
complete software system or major part of the system and then used for integration testing. The
Big Bang method is very effective for saving time in the integration testing process. However,
if the test cases and their results are not recorded properly, the entire integration process will
be more complicated and may prevent the testing team from achieving the goal of integration
testing.

A type of Big Bang Integration testing is called Usage Model testing. Usage Model
Testing can be used in both software and hardware integration testing. The basis behind this
type of integration testing is to run user-like workloads in integrated user-like environments.
In doing the testing in this manner, the environment is proofed, while the individual
components are proofed indirectly through their use.

Usage Model testing takes an optimistic approach to testing, because it expects to have
few problems with the individual components. The strategy relies heavily on the component
developers to do the isolated unit testing for their product. The goal of the strategy is to avoid
redoing the testing done by the developers, and instead flesh-out problems caused by the
interaction of the components in the environment.

For integration testing, Usage Model testing can be more efficient and provides better
test coverage than traditional focused functional integration testing. To be more efficient and
accurate, care must be used in defining the user-like workloads for creating realistic scenarios
in exercising the environment. This gives confidence that the integrated environment will work
as expected for the target customers.

Top-down and Bottom-up

Bottom Up Testing is an approach to integrated testing where the lowest level

components are tested first, then used to facilitate the testing of higher level components. The
process is repeated until the component at the top of the hierarchy is tested.

All the bottom or low-level modules, procedures or functions are integrated and then
tested. After the integration testing of lower level integrated modules, the next level of modules
will be formed and can be used for integration testing. This approach is helpful only when all
or most of the modules of the same development level are ready. This method also helps to
determine the levels of software developed and makes it easier to report testing progress in the
form of a percentage.
 Top Down Testing is an approach to integrated testing where the top integrated
modules are tested and the branch of the module is tested step by step until the end of the related
module.

Sandwich Testing is an approach to combine top down testing with bottom up testing.

The main advantage of the Bottom-Up approach is that bugs are more easily found. With Top-
Down, it is easier to find a missing branch link

Verification and validation

Verification and Validation are independent procedures that are used together for
checking that a product, service, or system meets requirements and specifications and that it
full fills its intended purpose. These are critical components of a quality management
system such as ISO 9000. The words "verification" and "validation" are sometimes preceded
with "Independent" (or IV&V), indicating that the verification and validation is to be performed
by a disinterested third party.

It is sometimes said that validation can be expressed by the query "Are you building
the right thing?" and verification by "Are you building it right?"In practice, the usage of these
terms varies. Sometimes they are even used interchangeably.

The PMBOK guide, an IEEE standard, defines them as follows in its 4th edition

• "Validation. The assurance that a product, service, or system meets the needs of the
customer and other identified stakeholders. It often involves acceptance and suitability with
external customers. Contrast with verification."
• "Verification. The evaluation of whether or not a product, service, or system complies
with a regulation, requirement, specification, or imposed condition. It is often an internal
process. Contrast with validation."

• Verification is intended to check that a product, service, or system (or portion thereof,
or set thereof) meets a set of initial design specifications. In the development phase,
verification procedures involve performing special tests to model or simulate a portion,
or the entirety, of a product, service or system, then performing a review or analysis of
the modelling results. In the post-development phase, verification procedures involve
regularly repeating tests devised specifically to ensure that the product, service, or
system continues to meet the initial design requirements, specifications, and regulations
as time progresses. It is a process that is used to evaluate whether a product, service, or
 system complies with regulations, specifications, or conditions imposed at the start of
a development phase. Verification can be in development, scale-up, or production. This
is often an internal process.

• Validation is intended to check that development and verification procedures for a

product, service, or system (or portion thereof, or set thereof) result in a product,
service, or system (or portion thereof, or set thereof) that meets initial requirements. For
a new development flow or verification flow, validation procedures may involve
modelling either flow and using simulations to predict faults or gaps that might lead to
invalid or incomplete verification or development of a product, service, or system (or
portion thereof, or set thereof). A set of validation requirements, specifications, and
regulations may then be used as a basis for qualifying a development flow or
verification flow for a product, service, or system (or portion thereof, or set thereof).
Additional validation procedures also include those that are designed specifically to
ensure that modifications made to an existing qualified development flow or
verification flow will have the effect of producing a product, service, or system (or
portion thereof, or set thereof) that meets the initial design requirements, specifications,
and regulations; these validations help to keep the flow qualified. It is a process of
establishing evidence that provides a high degree of assurance that a product, service,
or system accomplishes its intended requirements. This often involves acceptance of
fitness for purpose with end users and other product stakeholders. This is often an
external process.

• It is sometimes said that validation can be expressed by the query "Are you building
the right thing?" and verification by "Are you building it right?". "Building the right
thing" refers back to the user's needs, while "building it right" checks that the
specifications are correctly implemented by the system. In some contexts, it is required
to have written requirements for both as well as formal procedures or protocols for
determining compliance.

• It is entirely possible that a product passes when verified but fails when validated. This
can happen when, say, a product is built as per the specifications but the specifications
themselves fail to address the user’s needs.
Activities

Verification of machinery and equipment usually consists of design qualification (DQ),

installation qualification (IQ), operational qualification (OQ), and performance qualification
(PQ). DQ is usually a vendor's job. However, DQ can also be performed by the user, by
confirming through review and testing that the equipment meets the written acquisition
specification. If the relevant document or manuals of machinery/equipment are provided by
vendors, the later 3Q needs to be thoroughly performed by the users who work in an industrial
regulatory environment. Otherwise, the process of IQ, OQ and PQ is the task of validation. The
typical example of such a case could be the loss or absence of vendor's documentation for
legacy equipment or do-it-yourself (DIY) assemblies (e.g., cars, computers etc.) and, therefore,
users should endeavour to acquire DQ document beforehand. Each template of DQ, IQ, OQ
and PQ usually can be found on the internet respectively, whereas the DIY qualifications of
machinery/equipment can be assisted either by the vendor's training course materials and
tutorials, or by the published guidance books, such as step-by-step series if the acquisition of
machinery/equipment is not bundled with on- site qualification services. This kind of the DIY
approach is also applicable to the qualifications of software, computer operating systems and
a manufacturing process. The most important and critical task as the last step of the activity is
to generating and archiving machinery/equipment qualification reports for auditing purposes,
if regulatory compliances are mandatory.

Qualification of machinery/equipment is venue dependent, in particular items that are

shock sensitive and require balancing or calibration, and re-qualification needs to be conducted
once the objects are relocated. The full scales of some equipment qualifications are even time
dependent as consumables are used up (i.e. filters) or springs stretch out,
requiring recalibration, and hence re-certification is necessary when a specified due time
lapse Re-qualification of machinery/equipment should also be conducted when replacement of
parts, or coupling with another device, or installing a new application software and
restructuring of the computer which affects especially the pre-settings, such as
on BIOS, registry, disk drive partition table, dynamically-linked (shared) libraries, or an ini
file etc., have been necessary. In such a situation, the specifications of the
parts/devices/software and restructuring proposals should be appended to the qualification
document whether the parts/devices/software are genuine or not.

Torres and Hyman have discussed the suitability of non-genuine parts for clinical use
and provided guidelines for equipment users to select appropriate substitutes which are capable
to avoid adverse effects. In the case when genuine parts/devices/software are demanded by
some of regulatory requirements, then re-qualification does not need to be conducted on the
non-genuine assemblies. Instead, the asset has to be recycled for non-regulatory purposes.

When machinery/equipment qualification is conducted by a standard endorsed third

party such as by an ISO standard accredited company for a particular division, the process is
called certification. Currently, the coverage of ISO/IEC 15408 certification by an ISO/IEC
27001 accredited organization is limited; the scheme requires a fair amount of efforts to get
popularized.

7.1.6 System testing

System testing of software or hardware is testing conducted on a complete, integrated

system to evaluate the system's compliance with its specified requirements. System testing falls
within the scope of black box testing, and as such, should require no knowledge of the inner
design of the code or logic.

As a rule, system testing takes, as its input, all of the "integrated" software components
that have passed integration testing and also the software system itself integrated with any
applicable hardware system(s). The purpose of integration testing is to detect any
inconsistencies between the software units that are integrated together (called assemblages) or
between any of the assemblages and the hardware. System testing is a more limited type of
testing; it seeks to detect defects both within the "inter-assemblages" and also within the system
as a whole.

System testing is performed on the entire system in the context of a Functional

Requirement Specification(s) (FRS) and/or a System Requirement Specification (SRS).
System testing tests not only the design, but also the behavior and even the believed
expectations of the customer. It is also intended to test up to and beyond the bounds defined in
the software/hardware requirements specification

Types of tests to include in system testing

The following examples are different types of testing that should be considered during System
testing:

• Graphical user interface testing

• Usability testing
• Software performance testing
• Compatibility testing
• Exception handling
• Load testing
• Volume testing
• Stress testing
• Security testing
• Scalability testing
• Sanity testing
• Smoke testing
• Exploratory testing
• Ad hoc testing
• Regression testing
• Installation testing
• Maintenance testing Recovery testing and failover testing.
• Accessibility testing, including compliance with:
• Americans with Disabilities Act of 1990
• Section 508 Amendment to the Rehabilitation Act of 1973
• Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C)

Although different testing organizations may prescribe different tests as part of System testing,
this list serves as a general framework or foundation to begin with.

Structure Testing:

It is concerned with exercising the internal logic of a program and traversing particular
execution paths.
Output Testing:

• Output of test cases compared with the expected results created during design of test
cases.
• Asking the user about the format required by them tests the output generated or
displayed by the system under consideration.
• Here, the output format is considered into two was, one is on screen and another one is
printed format.
 • The output on the screen is found to be correct as the format was designed in the system
design phase according to user needs.
• The output comes out as the specified requirements as the user’s hard copy.

User acceptance Testing:

• Final Stage, before handling over to the customer which is usually carried out by the
customer where the test cases are executed with actual data.
• The system under consideration is tested for user acceptance and constantly keeping
touch with the prospective system user at the time of developing and making changes
whenever required.
• It involves planning and execution of various types of test in order to demonstrate that
the implemented software system satisfies the requirements stated in the requirement
document.
Two set of acceptance test to be run:

1. Those developed by quality assurance group.

2. Those developed by customer.
 CHAPTER-8

SYSTEM IMPLEMENTATION

8.1 System Module

• Input Video
• Image Classification
• Object Localization
• Object Detection

8.2 System Input Design

Input design is the raw data that is processed to produce output. During the input
design, the developers must consider the input devices such as PC, MICR, OMR, etc.

Therefore, the quality of system input determines the quality of system output. Well-
designed input forms and screens have following properties −

• It should serve specific purpose effectively such as storing, recording, and retrieving
the information.

• It ensures proper completion with accuracy.

• It should be easy to fill and straightforward.

• It should focus on user’s attention, consistency, and simplicity.

8.3 OUTPUT DESIGN

The design of output is the most important task of any system. During output design,
developers identify the type of outputs needed, and consider the necessary output controls
and prototype report layouts.
 CHAPTER-9

CONCLUSION & FUTURE ENCHANCEMENT

9.1 CONCLUSION

The visual object tracking is done on videos by training detector for YOLO coco
dataset consisting of more images for many classes. The moving object detection is done using
YOLO detector tracker for tracking the objects in consecutive frames. Accuracy and precision
can be worked upon by training the system for more epochs and fine tuning while training the
detector. Performance of tracker totally depends upon the detectors performance as it is a
tracker which follows tracking by detection approach.

9.2 FUTURE ENCHANCEMENT

The system can be trained for more classes (more types of objects) as it can be used for
different domains of videos and different objects can be detected and tracked on live cam. This
method can be extended to a visualization service on a smart device platform by using AR
technologies.
 APPENDIX-1

SOURCE CODE

# import the necessary packages

import numpy as np

import argparse

import imutils

import time

import cv2

import os

# construct the argument parse and parse the arguments

ap = argparse.ArgumentParser()

ap.add_argument("-i", "--input", required=True,

help="path to input video")

ap.add_argument("-o", "--output", required=True,

help="path to output video")

ap.add_argument("-y", "--yolo", required=True,

help="base path to YOLO directory")

ap.add_argument("-c", "--confidence", type=float, default=0.5,

help="minimum probability to filter weak detections")

ap.add_argument("-t", "--threshold", type=float, default=0.3,

help="threshold when applyong non-maxima suppression")

args = vars(ap.parse_args())

# load the COCO class labels our YOLO model was trained on

labelsPath = os.path.sep.join([args["yolo"], "coco.names"])

LABELS = open(labelsPath).read().strip().split("\n")

# initialize a list of colors to represent each possible class label

np.random.seed(42)

COLORS = np.random.randint(0, 255, size=(len(LABELS), 3),

dtype="uint8")

# derive the paths to the YOLO weights and model configuration

weightsPath = os.path.sep.join([args["yolo"], "yolov3.weights"])

configPath = os.path.sep.join([args["yolo"], "yolov3.cfg"])

# load our YOLO object detector trained on COCO dataset (80 classes)

# and determine only the *output* layer names that we need from YOLO

print("[INFO] loading YOLO from disk...")

net = cv2.dnn.readNetFromDarknet(configPath, weightsPath)

ln = net.getLayerNames()

ln = [ln[i[0] - 1] for i in net.getUnconnectedOutLayers()]

# initialize the video stream, pointer to output video file, and

# frame dimensions

vs = cv2.VideoCapture(args["input"])

writer = None

(W, H) = (None, None)

# try to determine the total number of frames in the video file

try:

prop = cv2.cv.CV_CAP_PROP_FRAME_COUNT if imutils.is_cv2() \

else cv2.CAP_PROP_FRAME_COUNT

total = int(vs.get(prop))

print("[INFO] {} total frames in video".format(total))

# an error occurred while trying to determine the total

# number of frames in the video file

except:
 print("[INFO] could not determine # of frames in video")

print("[INFO] no approx. completion time can be provided")

total = -1

# loop over frames from the video file stream

while True:

# read the next frame from the file

(grabbed, frame) = vs.read()

# if the frame was not grabbed, then we have reached the end

# of the stream

if not grabbed:

break

# if the frame dimensions are empty, grab them

if W is None or H is None:

(H, W) = frame.shape[:2]

# construct a blob from the input frame and then perform a forward

# pass of the YOLO object detector, giving us our bounding boxes

# and associated probabilities

blob = cv2.dnn.blobFromImage(frame, 1 / 255.0, (416, 416),

swapRB=True, crop=False)

net.setInput(blob)

start = time.time()

layerOutputs = net.forward(ln)

end = time.time()

# initialize our lists of detected bounding boxes, confidences,

# and class IDs, respectively

boxes = []

confidences = []

classIDs = []

# loop over each of the layer outputs

for output in layerOutputs:

# loop over each of the detections

for detection in output:

# extract the class ID and confidence (i.e., probability)

# of the current object detection

scores = detection[5:]

classID = np.argmax(scores)

confidence = scores[classID]

# filter out weak predictions by ensuring the detected

# probability is greater than the minimum probability

if confidence > args["confidence"]:

# scale the bounding box coordinates back relative to

# the size of the image, keeping in mind that YOLO

# actually returns the center (x, y)-coordinates of

# the bounding box followed by the boxes' width and

# height

box = detection[0:4] * np.array([W, H, W, H])

(centerX, centerY, width, height) = box.astype("int")

# use the center (x, y)-coordinates to derive the top

# and and left corner of the bounding box

x = int(centerX - (width / 2))

y = int(centerY - (height / 2))

 # update our list of bounding box coordinates,

# confidences, and class IDs

boxes.append([x, y, int(width), int(height)])

confidences.append(float(confidence))

classIDs.append(classID)

# apply non-maxima suppression to suppress weak, overlapping

# bounding boxes

idxs = cv2.dnn.NMSBoxes(boxes, confidences, args["confidence"],

args["threshold"])

# ensure at least one detection exists

if len(idxs) > 0:

# loop over the indexes we are keeping

for i in idxs.flatten():

# extract the bounding box coordinates

(x, y) = (boxes[i][0], boxes[i][1])

(w, h) = (boxes[i][2], boxes[i][3])

# draw a bounding box rectangle and label on the frame

 color = [int(c) for c in COLORS[classIDs[i]]]

cv2.rectangle(frame, (x, y), (x + w, y + h), color, 2)

text = "{}: {:.4f}".format(LABELS[classIDs[i]],

confidences[i])

cv2.putText(frame, text, (x, y - 5),

cv2.FONT_HERSHEY_SIMPLEX, 0.5, color, 2)

# check if the video writer is None

if writer is None:

# initialize our video writer

fourcc = cv2.VideoWriter_fourcc(*"MJPG")

writer = cv2.VideoWriter(args["output"], fourcc, 30,

(frame.shape[1], frame.shape[0]), True)

# some information on processing single frame

if total > 0:

elap = (end - start)

print("[INFO] single frame took {:.4f} seconds".format(elap))

print("[INFO] estimated total time to finish: {:.4f}".format(

elap * total))
 # write the output frame to disk

writer.write(frame)

# release the file pointers

print("[INFO] cleaning up...")

writer.release()

vs.release()
 APPENDIX-2

SCREENSHOTS
 REFERENCES

[1] Lele Xie, Tasweer Ahmad, Lianwen Jin , Yuliang Liu, and Sheng Zhang ,“ A New CNN-
Based Method for MultiDirectional Car License Plate Detection”, IEEE Transactions on
Intelligent Transportation Systems, ISSN (e): 1524-9050, Vol-19, Issue-02, Year-2018, pp.
507-517.

[2] L. Carminati, J. Benois-Pineau and C. Jennewein, “Knowledge-Based Supervised Learning

Methods in a Classical Problem of Video Object Tracking”, 2006 International Conference on
Image Processing, Atlanta, GA, USA, ISSN (e): 2381-8549, year-2006.

[3] Jinsu Lee, Junseong Bang and Seong-II Yang, “Object Detection with Sliding Window in
Images including Multiple Similar Object”, 2017 IEEE International Conference on
Information and Communication Technology Convergence (ICTC), Jeju, South Korea, ISBN
(e): 978-1-5090-4032-2, December-2017.

[4] Qichang Hu, Sakrapee Paisitkriangkrai, Chunhua Shen, Anton van den Hengel and Faith
Porikli,“Fast Detection of Multiple Objects in Traffic Scenes with Common Detection
Framework”, IEEE Transactions on Intelligent Transportation Systems, ISSN (e): 1558-0016,
Vol-17, Issue-04, Year-2016, pp. 1002-1014.

[5] Haihui Xie, Quingxiang Wu and Binshu Chen, “Vehicle Detection in Open Parks Using a
Convolutional Neural Network”, 20015 6th International Conference on Intelligent Systems
Design and Engineering Applications(ISDEA), Guiyang, China, ISSN (e): 978-1- 4673-9393-
5, August-2015.