Final Report Partial

Face Recognition Group No:
Chapter 1.
S.C.O.E. Dept of Information Technology 1 Year 2009-10

INTRODUCTION
The purpose of this document is to convict, analyze and define high-level needs
and features of the Face Recognition for voting system. It focuses on the capabilities
needed by the stakeholders, and the target users, and why these needs exist. The details of
how the FRVS fulfils these needs are detailed in the use-case and supplementary
specifications. The design of the target system is provided. The various aspects of
software like data, program, and interfaces are designed. The project sizing and
scheduling, work breakdown structure is done. The test plan for FRVS also provided
through the same document.
1.1 ABSTRACT
Face Recognition for voting system provides a computerized approach for

identification of the voters. The basic purpose of this project is to overcome manual errors
while identifying a person and to avoid all the malpractices performed at the time of election.
In normal voting system, voters are provided with election cards. The person
possessing his own election card is allowed to vote. Now the person who voted will have a
ink mark on his finger. In this above approach many malpractices are done. Fake election
cards are made. A voter can erase ink mark on his fingers. He may possess more than one
election card i.e. he will vote for more than once. In this approach the voter is confined to
vote only at a particular centre which is assigned to him.
So in order to avoid above problems we have designed a voting system which will be
based on computer vision and Bio-informatics. The images of all voters fulfilling specified
requirements are stored in the database. Now the image of the voter who have come for
voting is captured and is matched with other images in the database. If a match is found, he is
allowed to vote.

So in order to achieve above thing we are going to make use of following techniques:
1. Face Detection using OpenCv.
2. Segmentation using RGB technique.
3. Indexing
1.2 BACKGROUND AND BASICS

In normal voting system, voters are provided with election cards. The person
possessing his own election card is allowed to vote. Now the person who voted will have
a ink mark on his finger. In this above approach many malpractices are done. Fake
election cards are made. A voter can erase ink mark on his fingers. He may possess more
than one election card i.e. he will vote for more than once. In this approach the voter is
confined to vote only at a particular centre which is assigned to him.
So in order to avoid above problems we have designed a voting system which will
be based on computer vision and Bio-informatics. The images of all voters fulfilling
specified requirements are stored in the database. Now the image of the voter who have
come for voting is captured and is matched with other images in the database. If a match
is found, he is allowed to vote.
1.3 LITERATURE SURVEY

This is a new concept. Earlier a voter used to be given an identity card. At voting
centre he is allowed to vote if he possesses a valid i-card and if his name is there in the
list of voters maintained in the bunch of papers. No computer interface was used. Now in
this system voter’s info will be stored in the database along with his image. Camera at the
voting centre will be taking pictures of voters. It will compare this image with the images
stored in the database. If they match with each other, the person is allowed to vote. In our
system the malpractices mentioned above are avoided to a greater extent. After

recognition of face, system itself will auto-mark that voter has given his vote. As Bio-
Metrics recognition is used we can avoid creating of multiple profiles of a single person.
As all computers at voting centers are connected to one common server, the data will be
centralized and voters are allowed to give their vote from any center.
1.3.1 OpenCv
So in order to do this we will first detect a face from a picture. And this image of
face will be given to other modules for further processing. We get a ready module of face
detection in OpenCv.dll .
OpenCV implements a version of the face-detection technique first developed by
Paul Viola and Michael Jones—commonly known as the Viola-Jones detector[261]—and
later extended by Rainer Lienhart and Jochen Maydt[262] to use diagonal features (more on
this distinction to follow). OpenCV refers to this detector as the "Haar classifier" because
it uses Haar features[263] or, more precisely, Haar-like wavelets that consist of adding and
subtracting rectangular image regions before thresholding the result. OpenCV ships with
a set of pretrained object-recognition files, but the code also allows you to train and store
new object models for the detector. We note once again that the training
(createsamples(), haartraining()) and detecting (cvHaarDetectObjects()) code
works well on any objects (not just faces) that are consistently textured and mostly rigid.
The pretrained objects that come with OpenCV for this detector are in
…/opencv/data/haarcascades, where the model that works best for frontal face detection
is haarcascade_frontalface_alt2.xml. Side face views are harder to detect accurately with
this technique (as we shall describe shortly), and those shipped models work less well. If
you end up training good object models, perhaps you will consider contributing them as
open source back to the community.
1.3.2 RGB Technique

Then image will be divided into 9 parts. Each part will consist of one descriptor.
Now every color is combination of red, blue and green color. For each block we calculate
number of skin pixels and non skin pixels. For different persons number of skin pixels

will vary.
RGB (red, green, and blue) refers to a system for representing the colors to be
used on a computer display. Red, green, and blue can be combined in various proportions
to obtain any color in the visible spectrum. Levels of R, G, and B can each range from 0
to 100 percent of full intensity. Each level is represented by the range of decimal numbers
from 0 to 255 (256 levels for each color), equivalent to the range of binary numbers from
00000000 to 11111111, or hexadecimal 00 to FF. The total number of available colors is
256 x 256 x 256, or 16,777,216 possible colors.
In order to actually display the colors for all possible values, the computer display
system must have 24 bits to describe the color in each pixel. In display systems or modes
that have fewer bits for displaying colors, an approximation of the specified color will be
displayed.
1.3.3 .NET FRAMEWORK:
The Microsoft .NET Framework is a software framework available with several

Microsoft Windows operating systems. It includes a large library of coded solutions to
prevent common programming problems and a virtual machine that manages the
execution of programs written specifically for the framework. The .NET Framework is a
key Microsoft offering and is intended to be used by most new applications created for
the Windows platform.
The framework's Base Class Library provides a large range of features including
user interface, data and data access, database connectivity, cryptography, web application
development, numeric algorithms, and network communications. The class library is used
by programmers, who combine it with their own code to produce applications.
Programs written for the .NET Framework execute in a software environment that
manages the program's runtime requirements. Also part of the .NET Framework, this
runtime environment is known as the Common Language Runtime (CLR). The CLR
provides the appearance of an application virtual machine so that programmers need not
consider the capabilities of the specific CPU that will execute the program. The CLR also

provides other important services such as security, memory management, and exception
handling. The class library and the CLR together compose the .NET Framework.
Version 3.0 of the .NET Framework is included with Windows Server 2008 and
Windows Vista. The current version of the framework can also be installed on Windows
XP and the Windows Server 2003 family of operating systems.[2] A reduced "Compact"
version of the .NET Framework is also available on Windows Mobile platforms,
including smartphones.
PRINCIPLES DESIGN FEATURES:
Interoperability
Because interaction between new and older applications is commonly required,
the .NET Framework provides means to access functionality that is implemented in
programs that execute outside the .NET environment. Access to COM components is
provided in the System.Runtime.InteropServices and System.EnterpriseServices
namespaces of the framework; access to other functionality is provided using the
P/Invoke feature.
Common Runtime Engine

The Common Language Runtime (CLR) is the virtual machine component of
the .NET framework. All .NET programs execute under the supervision of the CLR,
guaranteeing certain properties and behaviors in the areas of memory management,
security, and exception handling.
Language Independence
The .NET Framework introduces a Common Type System, or CTS. The CTS
specification defines all possible datatypes and programming constructs supported by the
CLR and how they may or may not interact with each other. Because of this feature,
the .NET Framework supports the exchange of instances of types between programs

written in any of the .NET languages. This is discussed in more detail in Microsoft .NET
Languages.
Base Class Library

The Base Class Library (BCL), part of the Framework Class Library (FCL), is a
library of functionality available to all languages using the .NET Framework. The BCL
provides classes which encapsulate a number of common functions, including file reading
and writing, graphic rendering, database interaction and XML document manipulation.
Simplified Deployment
The .NET framework includes design features and tools that help manage the
installation of computer software to ensure that it does not interfere with previously
installed software, and that it conforms to security requirements.
Security
The design is meant to address some of the vulnerabilities, such as buffer
overflows, that have been exploited by malicious software. Additionally, .NET provides a
common security model for all applications.
Portability
The design of the .NET Framework allows it to theoretically be platform agnostic,
and thus cross-platform compatible. That is, a program written to use the framework
should run without change on any type of system for which the framework is
implemented. Microsoft's commercial implementations of the framework cover
Windows, Windows CE, and the Xbox 360.[3] In addition, Microsoft submits the
specifications for the Common Language Infrastructure (which includes the core class
libraries, Common Type System, and the Common Intermediate Language),[4][5][6] the C#
language,[7] and the C++/CLI language[8] to both ECMA and the ISO, making them
available as open standards. This makes it possible for third parties to create compatible
implementations of the framework and its languages on other platforms.

Architecture
Visual overview of the Common Language Infrastructure (CLI)

Common Language Infrastructure (CLI)
Main article: Common Language Infrastructure
The core aspects of the .NET Framework lie within the Common Language
Infrastructure, or CLI. The purpose of the CLI is to provide a language-neutral platform
for application development and execution, including functions for exception handling,
garbage collection, security, and interoperability. Microsoft's implementation of the CLI
is called the Common Language Runtime or CLR.

Assemblies
Main article: .NET assembly
The intermediate CIL code is housed in .NET assemblies. As mandated by

specification, assemblies are stored in the Portable Executable (PE) format, common on
the Windows platform for all DLL and EXE files. The assembly consists of one or more
files, one of which must contain the manifest, which has the metadata for the assembly.
The complete name of an assembly (not to be confused with the filename on disk)
contains its simple text name, version number, culture, and public key token. The public
key token is a unique hash generated when the assembly is compiled, thus two assemblies
with the same public key token are guaranteed to be identical from the point of view of
the framework. A private key can also be specified known only to the creator of the
assembly and can be used for strong naming and to guarantee that the assembly is from
the same author when a new version of the assembly is compiled (required to add an
assembly to the Global Assembly Cache).
Metadata
Main article: .NET metadata
All CLI is self-describing through .NET metadata. The CLR checks the metadata
to ensure that the correct method is called. Metadata is usually generated by language
compilers but developers can create their own metadata through custom attributes.
Metadata contains information about the assembly, and is also used to implement the
reflective programming capabilities of .NET Framework.
Security
.NET has its own security mechanism with two general features: Code Access
Security (CAS), and validation and verification. Code Access Security is based on
evidence that is associated with a specific assembly. Typically the evidence is the source

of the assembly (whether it is installed on the local machine or has been downloaded
from the intranet or Internet). Code Access Security uses evidence to determine the
permissions granted to the code. Other code can demand that calling code is granted a
specified permission. The demand causes the CLR to perform a call stack walk: every
assembly of each method in the call stack is checked for the required permission; if any
assembly is not granted the permission a security exception is thrown.
When an assembly is loaded the CLR performs various tests. Two such tests are
validation and verification. During validation the CLR checks that the assembly contains
valid metadata and CIL, and whether the internal tables are correct. Verification is not so
exact. The verification mechanism checks to see if the code does anything that is 'unsafe'.
The algorithm used is quite conservative; hence occasionally code that is 'safe' does not
pass. Unsafe code will only be executed if the assembly has the 'skip verification'
permission, which generally means code that is installed on the local machine.
.NET Framework uses appdomains as a mechanism for isolating code running in

a process. Appdomains can be created and code loaded into or unloaded from them
independent of other appdomains. This helps increase the fault tolerance of the
application, as faults or crashes in one appdomain do not affect rest of the application.
Appdomains can also be configured independently with different security privileges. This
can help increase the security of the application by isolating potentially unsafe code. The
developer, however, has to split the application into subdomains; it is not done by the
CLR.

Class library
Namespaces in the BCL[9]
System
System. CodeDom
System. Collections
System. Diagnostics
System. Globalization
System. IO
System. Resources
System. Text
System. Text.RegularExpressions
The .NET Framework includes a set of standard class libraries. The

class library is organized in a hierarchy of namespaces. Most of the built in

APIs are part of either System.* or Microsoft.* namespaces. These

class libraries implement a large number of common functions, such as file
reading and writing, graphic rendering, database interaction, and XML
document manipulation, among others. The .NET class libraries are
available to all .NET languages. The .NET Framework class library is
divided into two parts: the Base Class Library and the Framework Class
Library.
The Base Class Library (BCL) includes a small subset of the entire
class library and is the core set of classes that serve as the basic API of the
Common Language Runtime.[9] The classes in mscorlib.dll and some
of the classes in System.dll and System.core.dll are considered to
be a part of the BCL. The BCL classes are available in both .NET
Framework as well as its alternative implementations including .NET
Compact Framework, Microsoft Silverlight and Mono.
The Framework Class Library (FCL) is a superset of the BCL classes

and refers to the entire class library that ships with .NET Framework. It
includes an expanded set of libraries, including WinForms, ADO.NET,
ASP.NET, Language Integrated Query, Windows Presentation Foundation,
Windows Communication Foundation among others. The FCL is much
larger in scope than standard libraries for languages like C++, and
comparable in scope to the standard libraries of Java.
Memory management
The .NET Framework CLR frees the developer from the burden of
managing memory (allocating and freeing up when done); instead it does the

memory management itself. To this end, the memory allocated to

instantiations of .NET types (objects) is done contiguously from the
managed heap, a pool of memory managed by the CLR. As long as there
exists a reference to an object, which might be either a direct reference to an
object or via a graph of objects, the object is considered to be in use by the
CLR. When there is no reference to an object, and it cannot be reached or
used, it becomes garbage. However, it still holds on to the memory allocated
to it. .NET Framework includes a garbage collector which runs periodically,
on a separate thread from the application's thread, that enumerates all the
unusable objects and reclaims the memory allocated to them.
The .NET Garbage Collector (GC) is a non-deterministic, compacting,

mark-and-sweep garbage collector. The GC runs only when a certain amount
of memory has been used or there is enough pressure for memory on the
system. Since it is not guaranteed when the conditions to reclaim memory
are reached, the GC runs are non-deterministic. Each .NET application has a
set of roots, which are pointers to objects on the managed heap (managed
objects). These include references to static objects and objects defined as
local variables or method parameters currently in scope, as well as objects
referred to by CPU registers. When the GC runs, it pauses the application,
and for each object referred to in the root, it recursively enumerates all the
objects reachable from the root objects and marks them as reachable. It
uses .NET metadata and reflection to discover the objects encapsulated by
an object, and then recursively walk them. It then enumerates all the objects
on the heap (which were initially allocated contiguously) using reflection.
All objects not marked as reachable are garbage. This is the mark phase.

Since the memory held by garbage is not of any consequence, it is

considered free space. However, this leaves chunks of free space between
objects which were initially contiguous. The objects are then compacted
together, by using memcpy to copy them over to the free space to make
them contiguous again. Any reference to an object invalidated by moving
the object is updated to reflect the new location by the GC. The application
is resumed after the garbage collection is over.
The GC used by .NET Framework is actually generational. Objects

are assigned a generation; newly created objects belong to Generation 0.
The objects that survive a garbage collection are tagged as Generation 1,
and the Generation 1 objects that survive another collection are Generation
2 objects. The .NET Framework uses up to Generation 2 objects. Higher
generation objects are garbage collected less frequently than lower
generation objects. This helps increase the efficiency of garbage collection,
as older objects tend to have a larger lifetime than newer objects. Thus, by
removing older (and thus more likely to survive a collection) objects from
the scope of a collection run, fewer objects need to be checked and
compacted.

1 .4 PROBLEM DEFINITION
1.4.1 Vision Document/ Synopsis
1. Sponsor Status : INHOUSE
2. Objective / Aim :
To provide a means to conduct fair voting by introducing face
recognition system of voters. With the help of this system we can detect repeating
voters and eliminate chance of winning candidates using unfair means to win.
• Problem: Provide a means to detect fraud voters by
- Maintaining Voter image database
- Detecting the real time voter image using a camera
- Comparing Current voter image with the stored images.
1.4.2. SOFTWARE REQUIRENMENT SPECIFICATION:
1.4.2.1. INTRODUCTION
1.1) PROBLEM STATEMENT
This product helps to avoid malpractices carried out at voting center.
The modules namely Image processor and Face Recognizer can be

used in many applications such as security surveillance, validation

checking at exam centers etc.
The algorithm used here allows fast one to many image matching
without the use of expensive hardware. This product will allow voter to vote
from any voting center.
1.2) Scope Statement
There are various algorithms exist for face recognition. Earlier

algorithms apply one to one image matching. If we want to recognize
a face using those algorithms then we have to compare target image
with each source image in database. This takes a large time for
recognition if there exists millions of source images.
This is a new concept. Here a camera will be taking pictures of
voters. It will compare this image with the images stored in the
database. If they match with each other, the person is allowed to vote.
Now earlier voters possessing election cards were allowed to vote. No
computer interface was there. In our system the malpractices
mentioned above are avoided to a greater extend. After recognition of
face, system itself will auto-mark that voter has given his vote. As
Bio-Metrics recognition is used we can avoid creating of multiple
profiles of a single person. As all computers at voting centers are
connected to one common server, the data will be centralized and
voters are allowed to give their vote from any center.
1.4.2.2) Proposed System ( Project )
System Overview: The SRS contains the problem statement, summary of

capabilities, overview, system and environment requirements. The rest of the
document contains the software design specifications, project plan and the test plan

1.4.2.3) Project Status: -
Object oriented concepts are used while coding and documentation

of codes and use of self explanatory variables are used.
1. Classification
Sr.No Requirement Priority Expected Result

1 Face Detection High Detection of voter's face from
image captured by camera
2. Image Comparison High Comparison of target image with
source image from database
3. Face Recognition High Fetch voter's profile from
database on successful
comparison
4. GUI High. The Operation must be simplified
by the GUI design so as to make
it easy for the user to understand
5. Authentication High The system should log on to the
system only the authentic users.

Definition :
A system to create software for detecting fraud voters.
3. Responsibilities:
The primary responsibility of the system is to inform electoral
officers.
This system performs following roles:-
a) Manage Voter Details,

b) Manage Voter Images,
c) Capturing voter image using a web cam,
d) Comparing Voter image with the image database,
e) Interacting with user via response messages to the given input.
This system provides an easy process for Officer’s to identify fraud voters.
1.4.2.4) Requirement
1. Hardware Requirements
a) Pentium 4 system or above
b) 512 Ram or above
c) Web camera
2. Software Requirements
a) OS: Window XP SP2
b) Front End: C# 3.5 .Net Framework
c) Back End: MS SQL 2005
d) Development Environment : Visual Studio 2008

Chapter 2.
Project Planning and Management

2.1 Project Planning And Management

To solve actual problems, a software engineer must incorporate a
development strategy that encompasses the process, methods and tools. This
strategy is often called as a process model or software engineering paradigm.
Project model is based on nature of the project and its applications.
From among the different models, we have followed the Incremental
Software Development Model.
Analysis
Design

Coding
Testing
Maintenance
2.1.1 Incremental Software Development Model

The incremental model called as classic life cycle or waterfall model,
suggest a systematic, sequential approach to software development and begins at
the system level and progresses through analysis, design, coding, testing and
maintenance. Fig illustrates the linear sequential model for software engineering.
2.2 Feasibility Study

Technically the system is very sound as no one apart from the administrator
can access to the generic code. Only the administrator has the privileges to update
or make the changes to the code
Clients and end user would get the features for their specific requirements.
The project feasibility was examined on the following dimensions:
1 Technology
2 Economy
3 Resources
2.2.1 Technology

The project involved learning a .NET Technology. The basic requirement

for the project development was to get familiar with Visual Studio's .NET
environment along with the fundamentals of databases. So, we concluded that the
project was feasible on the dimensions of technology. The books used for learning
and references include various books on .NET along with e-books and reference
available on the Internet for the Image Processing.
2.2.2 Economy
Economic feasibility or cost benefit analysis is generally oriented to check if
the conceptual system is economical viable with the current available system. The
cost incurred in the development of this project was only the resources.
2.2.3 Resources
The second project-planning task was the estimation of the resources
required to accomplish the software development effort. There are three tiers of
resources – human resources, reusable resources and hardware/software tools. This
formed a development pyramid with development environment consisting of
Hardware/Software tools as base, reusable components as middle tier, and people
as a primary resource at the top.
2.3 System Requirement

2.3.1 Hardware requirements
CPU Pentium4 1GHZ

Memory 128/256 MB RAM
Display options 15inch monitor
I/P device Keyboard, Mouse
Connectivity Internet connection
Power supply Normal
Web Camera High resolution
2.3.2 Software requirements
Operating System Windows XP, LINUX

Network Protocol HTTP,XML
Application Software Visual Studio .NET
2.4 Estimation & Efforts
The constructive cost model is generally used for estimation measures of

cost, project duration, manpowered, etc.
Like all estimation models the COCOMO models requires sizing
information. This information can be specified in the form of
• Object point
• Function points(FP)
• Lines of source code(KLOC)

For our project, we use thw = e sizing information in the forms of lines of
source code(KLOC)
• Total lines of code for our project, KLOC = 15K(approx)
• Cost of each person per month, CP = Rs 20000/- (Cost per person month)
• Equation for calculation of Efforts in person –months for COCOMO model

is:
E= a *(KLOC)b
Where ,
a = 2.4
b = 1.05, for an organic project
E = Efforts in person months
• Equation for calculation of duration of Projectin month for the COCOMO

model is
D= a*(E)b
Where,
a = 2.5
b = 0.38, for an organic project
D = Duration of projects in months
• Equation for calculation of Number of people required for completion of

project, using the COCOMO model is:
N = E/D
Where,
N = Number of people required

E = Efforts in person months
D = Duration of projects in months
• Equation for calculation of cost of project, using the COCOMO model is :
C = D * Cp
Where,
C = Cost of project
D = Duration of project in months
Cp = Cost incurred per person
• Efforts:
E = 2.4(111.05
E = 28 person- month.
Total of 28 person- months are required to complete the project successfully.
• Duration of Project:
D = 2.5*(e)0.38
D = & months
The approximate duration of the project is 28 months.
• Number of people incurred for the project:
N = 28/7

N = 4.00
N ~ 4 People.
Therefore 4 people are required to successfully complete the project on

schedule.
• Cost of project:
C = 4* 14000
C = 56,000
Therefore cost of project is approximately Rs.56,000.
2.5Risks
1. Product size Risks:

Size estimate may be significantly low.
Game rules or requirements may change the Project’s requirements.
2. Business Impact Risks:

Quality of product documentation and coding that must be produced may be
low.
Unavailability of team members
Conflicts between team members

Unrealistic delivery deadlines where slippage may occur
3. Process Risks:
Lack of experience in Project Planning
First time dealing with big projects
Software may not be easily tested
Reviews may not be conducted regularly
4. Development Risks
Lack of training on Java and algorithms understanding is poor.
2.6 Project Scheduling
Id Task Name Duration Start Date Finish Date

0 Plan 175 days 08/15/09 04/02/10
1 Requirement Analysis 62 days 08/15/09 10/16/09
2 Requirement Gathering 12 days 08/15/09 08/27/09
3 Analysis Modeling 10 days 09/18/09 09/28/09
4 Functional Modeling 25 days 08/30/09 09/24/09
5 Behavioral Modeling 5 days 09/02/09 09/07/09
6 Structural Analysis 10 days 09/06/09 09/16/09
7 Analysis 18 days 09/18/09 10/06/09
8 Use case Modeling 3 10/04/09 10/07/09
9 ER Modeling 6 09/18/09 09/24/09
10 DFD Modeling 4 10/06/09 10/10/09
11 Data Modeling 5 10/07/09 10/11/09
12 Design 43 10/12/09 01/01/10
13 Form designing 8 01/01/10 01/20/10
14 Code designing 35 01/07/10 02/15/10

15 Development and 70 01/01/10 03/11/10

Coding
16 Form Creation 5 01/01/10 01/06/10
17 Coding 45 01/28/10 03/17/10
18 Integration 20 03/18/10 03/28/10
19 Testing and validation 8 03/02/10 03/30/10
20 Unit testing 2 03/02/10 03/04/10
21 Module testing 2 03/17/10 03/19/10
22 Functional testing 2 03/17/10 03/19/10
23 Integration testing 2 03/28/10 03/30/10
2.6.1 Time Line Chart


Chapter 3.
ANALYSIS
3.1 Use case diagram

uc Use Case Model
EA 6.5 Unregistered Trial Version EA 6.5 Unregistered

Syst em Trial Version EA 6.5 Unregistered T rial V
EA 6.5 Unregistered Trial Version EALogin

6.5 Unregistered Trial Version EA 6.5 Unregistered T rial V
EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered T rial V
Admi n
Set Voter's detai ls

«include» Trial Version EA 6.5 Unregistered T rial V
UpdateDb

«include»Trial Version EA 6.5 Unregistered T rial V
Del ete Record
«include»
Edit Record
Use case ID 1
EA 6.5Name
Unregistered
of Use caseTrial Version EA 6.5Store
Unregistered Trialrecord
& Fetch Voter's Version EA 6.5 Unregistered T rial V
EA 6.5 Unregistered
S.C.O.E. TrialTechnology
Dept of Information 31
Version EA 6.5 Unregistered Trial VersionYear
EA2009-10
6.5 Unregistered T rial V
Actors Administrator
Description Admin adds or updates or deletes voter's
profile in database
Preconditions 1.
Post conditions Voter's profile is stored, updated or deleted.
Assumptions Voter must be minimum 21 yrs old to add
record
Normal Course Administrator adds.
Benefiting Actor Admin
3.2 DATA FLOW DIAGRAMS


3.3 Activity Diagram

act Activ ity
EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version
Process Im age
get Image
Digi tize Im age
EA 6.5 Unregistered Trial Segment

Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version
Image
Cr eate Descriptor
EA 6.5 Unregistered Trial Version

Assign EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version
Inadex v alues
Recogni ze Image

Search Im age EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version
dependi ng on
Descr iptor v al ues
Compare descriptors
[not f ound]
[found i mage]
Allow user to v ote Don't allow user to

EA 6.5 Unregistered Trial Version EA v6.5
ote
Unregistered Trial Version EA 6.5 Unregistered Trial Version
EA 6.5S.C.O.E.
Unregistered
Dept Trial Version Technology
of Information EA 6.5 Unregistered Trial
35 Version EA 6.5 Unregistered Trial
YearVersion
2009-10
3.2 Class Diagram

class Use Case Model

EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregister
System

+ processIEA 6.5
mage(I Unregistered
mage) : void Trial Version EA 6.5 Unregister
+ recognizeFace() : void
+ showDetail s() : void
EA 6.5 Unregistered Trial Version<<uses>>

<<uses>>
EA 6.5 Unregistered
<<uses>>
Trial Version EA 6.5 Unregister
EA 6.5 Unregistered
Admi n
Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregister
VoterProfil e ImageP rocessor
- logi nName: String - Address: St ri ng
EA 6.5 Unregistered Trial Version EA 6.5<<uses>>
- passwd: String - Unregistered Trial
+ assignDescript
Age: Integer ors()Version
: void EA 6.5 Unregister
- DO B: Dat e + assignIndexValue() : void
+ getAdminInfo() : void - Image: Image + getImage() : voi d
+ setAdminInfo() : voi d - name: St ring + segmentI mage() : void
+ get VoterInfo() : voi d

EA 6.5 Unregistered Trial Version EA 6.5 Unregistered<<uses>>
+ Trial Version EA 6.5 Unregister
setVot erInfo() : void
FaceRecognizer
V oterList
+ add() : void
EA 6.5 Unregistered Trialpt ors()
+ compareDescri Version
: voi d EA 6.5 Unregister
+ get DescriptorDetails() : void
+ delete() : voi d + isImageSame() : bool ean
+ search() : voi d
3.3EA 6.5 Unregistered

Sequence Diagram Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregister
EA 6.5 Unregistered T rial Version

s d Us e C as e M ode l EA 6.5 Unregistered T rial Version
E A 6.5 U nregistered T rial

:S yste m
EA 6.5 Unregistered
: Ad m in :V ot er
T rial Version E A 6.5
Im a ge P ro cesso r
U nregistered T rial
Face Reco gn i ze r
Ad m in
EA 6.5 Unregistered
lo g in ()
T rial Version
g e tA dm i nI nf o()
EA 6.5 Unregistered T rial
proviVersion
de In fo () EA 6.5 Unregistered T rial Version
V al id at eU se r()
EA
a lt 6.5 Unregistered
re je ctUser() T rial Version
[ in val id u se r]
EA
[ val id6.5
u se r] Unregistered
a ccep tU se r() T rial Version
se tV ot erDe ta ils()
EAat e6.5
<<cre >> Unregistered T rial Version
se tvo te rDe t ai ls()
EA 6.5 Unregistered
set Ca p tu re dI m ag e () T rial Version
se tI m ag e ()
EA 6.5 Unregistered T rial Version E A 6.5 U nregistered T rial
di gi tize Im a g e()

EA 6.5 Unregistered T rial VersionE A 6.5 U nregistered T rial
seg m e n tIm a g e()

p ro vi E Aescrip
d eD 6.5to rs()
U nregistered T rial
com p a re Im a g e()
i sFo u nd Im a g e ()
EA 6.5 Unregistered
al t aT
llo rial
wU se r()Version
[Im a g e Fo u nd ]
EA 6.5 Unregistered
[n ot Fo u n d] dT rial Version
en yUser()





3.4 EA 6.5 Unregistered T rial Version
EA 6.5
S.C.O.E. DeptUnregistered T rial Version
of Information Technology EA 6.5
38 Unregistered T rial Version
YearE A 6.5 U nregistered T rial
2009-10

3.5 State Machine Diagram

stm Use Case Model
EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered T rial Vers
Processing image Recognizing Face processing image
[im age]
digitizing image
searching images
with index v alue
recognizing image
nearer to that of
target image
EA 6.5 Unregistered
segmenting the Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered T rial Vers
image
Compar ing target [found i mage] [not found]
image and source
EA 6.5 Unregistered
craeting
descriptors
Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered T rial Vers
image
EA 6.5 Unregistered
[descriptor]
Trial Version EA 6.5 Unregisteredallow
Trial
user Version
to v ote EA 6.5 Unregistered T rial Vers
deny user
EA 6.5 Unregistered
assigning index Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered T rial Vers
v alues
EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregist
3.6 Deployment Diagram
depl oyment Use Case Model
Voting Machine
Admin Pc
Internet
EA 6.5 Unregistered
DB servTrial
er Version EA Apllication
6.5 Unregistered
Server Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregist
EA 6.5 Unregistered
Profile Trial Version EA 6.5System
Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregist
ImageProcessor
Image
Processor
Face Recognizer
EA 6.5 Unregistered
Face Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregist
Recognizer
Admin
Backup
Backup
S.C.O.E.
EA 6.5 Dept of Information
Unregistered Technology
Trial Version 40 Trial Version EA 6.5 Unregistered
EA 6.5 Unregistered Year 2009-10
Trial Version EA 6.5 Unregist
Chapter 5.
IMPLEMENTATION AND CODING

5.1 GUI Design

5.1.1 Login for Adminitrator
Fig. 4.1

5.1.2 Add Voter
Fig.4.2
5.1.3 Add Voters image
Fig. 4.2

5.1.4 Manage Voter-List
Fig. 4.4
5.1.5 Manage Voter’s image
Fig. 4.5

5.1.6 Face Detection
Fig 4.6
5.1.7 Train faces
Fig. 4.7
5.1.8 Structure of Descriptors

Fig. 4.8
5.1.9 Descriptor for Face detection
Fig. 4.9
5.2Software Design Specification
5.2.1 Introduction

Basically the system is divided into two parts viz. Computer vision and File
management. Computer vision is further divided into two parts. First is Low-level
computer vision and second is high-level computer vision. In Low-level computer vision
we are going to perform digitizing of image file, Segmentation. I/p to this level is original
image file. This is processed into discrete grid and further into decriptors. In high-level
computer vision we are going to perform image-indexing and face recognition. I/p to this
system is collection of relevant data obtained from low-level computer vision. File
management will include details of voters, and managing it.
5.2.2 Data design
5.2.2.1 Internal software data structure
Data structures that we are going to use for computer vision are:
1)Matrices
Image function is dependant on two variables viz (x,y) co-ordinates in a x-y plane.
Every (x,y) will correspond to a brightness value stored in it.
So a original image file will be represented using a matrix structure. Further this image
will be sampled into discrete grid. For this we will require co-occurence matrix.
2)Chain codes
When the discrete file is quantised it is converted into digital form. This file is
segmented into different objects containing information about borders. So in order tostore
borders we require chain codes. Instead of chain codes if we use matrix this will consume
lot of space. So its worth using chain codes.
3)Relational structures
Here objects are identified by there names and the relationship between them can
be noted here. This is helpful in creation of decriptors.

4)Files
Patient's Profile will have one class. Different instances of this class will have
information about different patients. This instances will be entered into a binary file
format.
5.2.2.4 Database description

Hierarchical Directory structure will be used to store details. Every patient will
have a folder. His binary file, image will be stored in this structure. Descriptors obtained
for that particular patient will also be stored in this folder
5.3 Operational details

The project is divided into several modules. But the modules worth discussing are
as follows
1) Image handler
2) Face trainer
3) Recognizor
5.3.1 Image Handler

This module is responsible for detection of face. When we have a picture of a
person, instead of applying segmentation to whole image, we apply segmentation to the
face only. For that we first identify the face from the picture with the help of OpenCv.
Lets first know about OpenCv and then we will study the code.
5.3.1.1 OpenCv
OpenCV implements a version of the face-detection technique first developed by
Paul Viola and Michael Jones—commonly known as the Viola-Jones detector[261]—and
later extended by Rainer Lienhart and Jochen Maydt[262] to use diagonal features (more on
this distinction to follow). OpenCV refers to this detector as the "Haar classifier" because
it uses Haar features[263] or, more precisely, Haar-like wavelets that consist of adding and

subtracting rectangular image regions before thresholding the result. OpenCV ships with
a set of pretrained object-recognition files, but the code also allows you to train and store
new object models for the detector. We note once again that the training
(createsamples(), haartraining()) and detecting (cvHaarDetectObjects()) code
works well on any objects (not just faces) that are consistently textured and mostly rigid.
The pretrained objects that come with OpenCV for this detector are in
…/opencv/data/haarcascades, where the model that works best for frontal face detection
is haarcascade_frontalface_alt2.xml. Side face views are harder to detect accurately with
this technique (as we shall describe shortly), and those shipped models work less well. If
you end up training good object models, perhaps you will consider contributing them as
open source back to the community.
Haar Like Features:What is that?
A recognition process can be much more efficient if it is based on the detection of

features that encode some information about the class to be detected. This is the case of
Haar-like features that encode the existence of oriented contrasts between regions in the
image. A set of these features can be used to encode the contrasts exhibited by a human
face and their spacial relationships. Haar-like features are so called because they are
computed similar to the coefficients in Haar wavelet transforms.
The object detector of OpenCV has been initially proposed by Paul Viola and
improved by Rainer Lienhart. First, a classifier (namely a cascade of boosted classifiers
working with haar-like features) is trained with a few hundreds of sample views of a
particular object (i.e., a face or a car), called positive examples, that are scaled to the
same size (say, 20x20), and negative examples - arbitrary images of the same size.
After a classifier is trained, it can be applied to a region of interest (of the same
size as used during the training) in an input image. The classifier outputs a "1" if the
region is likely to show the object (i.e., face/car), and "0" otherwise. To search for the
object in the whole image one can move the search window across the image and check
every location using the classifier. The classifier is designed so that it can be easily

"resized" in order to be able to find the objects of interest at different sizes, which is more
efficient than resizing the image itself. So, to find an object of an unknown size in the
image the scan procedure should be done several times at different scales.
The word "cascade" in the classifier name means that the resultant classifier
consists of several simpler classifiers (stages) that are applied subsequently to a region of
interest until at some stage the candidate is rejected or all the stages are passed. The word
"boosted" means that the classifiers at every stage of the cascade are complex themselves
and they are built out of basic classifiers using one of four different boosting techniques
(weighted voting). Currently Discrete Adaboost, Real Adaboost, Gentle Adaboost and
Logitboost are supported. The basic classifiers are decision-tree classifiers with at least 2
leaves. Haar-like features are the input to the basic classifers.The feature used in a
particular classifier is specified by its shape , position within the region of interest and the
scale (this scale is not the same as the scale used at the detection stage, though these two
scales are multiplied).
Ok. Enough of the theory part. Now to the coding part:
// Create memory for calculations

static CvMemStorage* storage = 0;
// Create a new Haar classifier

static CvHaarClassifierCascade* cascade = 0;
// Function prototype for detecting and drawing an object from an image

void detect_and_draw( IplImage* image );
// Create a string that contains the cascade name

const char* cascade_name =
"haarcascade_frontalface_alt.xml";
/* "haarcascade_profileface.xml";*/

// Main function, defines the entry point for the program.

int main( int argc, char** argv )
{
// Structure for getting video from camera or avi

CvCapture* capture = 0;
// Images to capture the frame from video or camera or from file

IplImage *frame, *frame_copy = 0;
// Used for calculations

int optlen = strlen("--cascade=");
// Input file name for avi or image file.

const char* input_name;
// Check for the correct usage of the command line

if( argc > 1 && strncmp( argv[1], "--cascade=", optlen ) == 0 )
{
cascade_name = argv[1] + optlen;
input_name = argc > 2 ? argv[2] : 0;
}
else
{
fprintf( stderr,
"Usage: facedetect --cascade=\"<cascade_path>\" [filename|camera_index]\n" );
return -1;
/*input_name = argc > 1 ? argv[1] : 0;*/
}

// Load the HaarClassifierCascade

cascade = (CvHaarClassifierCascade*)cvLoad( cascade_name, 0, 0, 0 );
// Check whether the cascade has loaded successfully. Else report and error and quit
if( !cascade )
{
fprintf( stderr, "ERROR: Could not load classifier cascade\n" );
return -1;
}
// Allocate the memory storage

storage = cvCreateMemStorage(0);
// Find whether to detect the object from file or from camera.

if( !input_name || (isdigit(input_name[0]) && input_name[1] == '\0') )
capture = cvCaptureFromCAM( !input_name ? 0 : input_name[0] - '0' );
else
capture = cvCaptureFromAVI( input_name );
// Create a new named window with title: result

cvNamedWindow( "result", 1 );
// Find if the capture is loaded successfully or not.
// If loaded succesfully, then:

if( capture )
{
// Capture from the camera.
for(;;)

{
// Capture the frame and load it in IplImage
if( !cvGrabFrame( capture ))
break;
frame = cvRetrieveFrame( capture );
// If the frame does not exist, quit the loop

if( !frame )
break;
// Allocate framecopy as the same size of the frame

if( !frame_copy )
frame_copy = cvCreateImage( cvSize(frame->width,frame->height),
IPL_DEPTH_8U, frame->nChannels );
// Check the origin of image. If top left, copy the image frame to frame_copy.
if( frame->origin == IPL_ORIGIN_TL )
cvCopy( frame, frame_copy, 0 );
// Else flip and copy the image
else
cvFlip( frame, frame_copy, 0 );
// Call the function to detect and draw the face

detect_and_draw( frame_copy );
// Wait for a while before proceeding to the next frame

if( cvWaitKey( 10 ) >= 0 )
break;
}

// Release the images, and capture memory

cvReleaseImage( &frame_copy );
cvReleaseCapture( &capture );
}
// If the capture is not loaded succesfully, then:

else
{
// Assume the image to be lena.jpg, or the input_name specified
const char* filename = input_name ? input_name : (char*)"lena.jpg";
// Load the image from that filename

IplImage* image = cvLoadImage( filename, 1 );
// If Image is loaded succesfully, then:

if( image )
{
// Detect and draw the face
detect_and_draw( image );
// Wait for user input

cvWaitKey(0);
// Release the image memory

cvReleaseImage( &image );
}
else
{
/* assume it is a text file containing the
list of the image filenames to be processed - one per line */

FILE* f = fopen( filename, "rt" );

if( f )
{
char buf[1000+1];
// Get the line from the file

while( fgets( buf, 1000, f ) )
{
// Remove the spaces if any, and clean up the name

int len = (int)strlen(buf);
while( len > 0 && isspace(buf[len-1]) )
len--;
buf[len] = '\0';
// Load the image from the filename present in the buffer

image = cvLoadImage( buf, 1 );
// If the image was loaded succesfully, then:

if( image )
{
// Detect and draw the face from the image
detect_and_draw( image );
// Wait for the user input, and release the memory

cvWaitKey(0);
cvReleaseImage( &image );
}
}
// Close the file

fclose(f);
}
}
// Destroy the window previously created with filename: "result"

cvDestroyWindow("result");
// return 0 to indicate successfull execution of the program

return 0;
}
// Function to detect and draw any faces that is present in an image

void detect_and_draw( IplImage* img )
{
int scale = 1;
// Create a new image based on the input image

IplImage* temp = cvCreateImage( cvSize(img->width/scale,img->height/scale), 8, 3 );
// Create two points to represent the face locations

CvPoint pt1, pt2;
int i;
// Clear the memory storage which was used before

cvClearMemStorage( storage );
// Find whether the cascade is loaded, to find the faces. If yes, then:
if( cascade )

// There can be more than one face in an image. So create a growable sequence of faces.
// Detect the objects and store them in the sequence
CvSeq* faces = cvHaarDetectObjects( img, cascade, storage,
1.1, 2, CV_HAAR_DO_CANNY_PRUNING,
cvSize(40, 40) );
// Loop the number of faces found.

for( i = 0; i < (faces ? faces->total : 0); i++ )
{
// Create a new rectangle for drawing the face
CvRect* r = (CvRect*)cvGetSeqElem( faces, i );
// Find the dimensions of the face,and scale it if necessary

pt1.x = r->x*scale;
pt2.x = (r->x+r->width)*scale;
pt1.y = r->y*scale;
pt2.y = (r->y+r->height)*scale;
// Draw the rectangle in the input image

cvRectangle( img, pt1, pt2, CV_RGB(255,0,0), 3, 8, 0 );
}
}
// Show the image in the window named "result"

cvShowImage( "result", img );
// Release the temp image created.

cvReleaseImage( &temp );

5.3.2 FaceTrainer
This module is used to do the segmentation on the picture containing face. The
picture is stored in a array known as bitmap. Here each pixel is identified by a row
number and a column number. We are going to divide the picture into 9 blocks. And then
for each block we are going to calculate number of skin pixels, non skin pixels and
average red, average blue and average green. Before getting to the code lets first discuss
about RGB technique.
5.3.2.1 RGB Technique
RGB (red, green, and blue) refers to a system for representing the colors to be
used on a computer display. Red, green, and blue can be combined in various proportions
to obtain any color in the visible spectrum. Levels of R, G, and B can each range from 0
to 100 percent of full intensity. Each level is represented by the range of decimal numbers
from 0 to 255 (256 levels for each color), equivalent to the range of binary numbers from
00000000 to 11111111, or hexadecimal 00 to FF. The total number of available colors is
256 x 256 x 256, or 16,777,216 possible colors.
In order to actually display the colors for all possible values, the computer
display system must have 24 bits to describe the color in each pixel. In display systems or
modes that have fewer bits for displaying colors, an approximation of the specified color
will be displayed.
5.3.2.1 Code
//Image is stored into array known as Bitmap. We can retrieve height and width of the
//picture as follows.
Bitmap b = new Bitmap(faceImage);
w = b.Width;
h = b.Height;
//To point to a single pixel and retrieve its RGB combination we use Color class.
Color col;
col = img.GetPixel(x + i, y + j);

//We can retrieve the amount of red, green, blue needed to paint that pixel as follows
col.R
col.G
col.B
//For the color white the amount red , green and blue must all be above 225
col.R > 225 && col.G > 225 && col.B > 225
//For the color black the amount red , green and blue must all be below 30
col.R < 30 && col.G < 30 && col.B < 30
//To identify skin pixels the combination must be as follows

int skinPixelCount(ref Bitmap memImage)
{
int x, y, cnt;
Color c;
cnt = 0;
bool flag;
for (x = 0; x < memImage.Width; x++)
{
for (y = 0; y < memImage.Height; y++)
{
try
{
c = memImage.GetPixel(x, y);
if (c.R > 95 && c.G > 40 && c.B > 20)
{
if ((GetMaxRGB(c.R, c.G, c.B) - GetMinRGB(c.R, c.G, c.B)) > 15)
{
if (Math.Abs(c.R - c.G) > 15 && c.R > c.G && c.R > c.B)

{
flag = true;
}
else
{
flag = false;
}
}
else
{
flag = false;
}
}
else
{
flag = false;
}
if (flag == true)
cnt++;
}
catch
{}
}
}
return cnt;
}
//Now this counts for each block are written in a XML file using XmlWriter class.
5.3.3 Recognizer
5.3.3.1 Algorithm

1. Percentage of skin pixels per block will be calculated.
2. Now we will consider 1st block of all pictures.
We will make groups based on percentage of skin pixels. Pictures containing 0-15%
of skin pixels in 1st block will be placed in 1st group, Pictures containing 10-25% of
skin pixels will be placed in 2nd group and so on.
3. This groups will be further sub-grouped based on above criteria but now we will refer
2nd block.
4. We will keep doing above process till the last block.
5. Now the target image of voter which will be captured at voting centre will be
processed and its descriptors will get created.
6. Here the percentage of skin pixels in first block will be taken into consideration.
Depending on the percentage we will compare it with the respective group. Again the
process is repeated for remaining blocks.
7. In the last block if it matches with a image in the database we say that the recognition
is successful else it is unsuccessful.

Chapter 5.
TESTING

5.1 Introduction
The Software Test Plan (STP) is designed describe the test objectives, approach, scope,
strategy, methodology and schedule of all testing activities.
5.1.1 Objectives
Testing is the major part of any solution for proper and effective working. Various
modules like Image processing, artificial intelligence and interface (front end) need to be tested
as individual unit as well as after integrating together. Major objective is to reduce the time
response and to work out the strategies correctly. Since the incremental model is used for
development of application testing will be done after every increment.
5.1.2 Testing Strategies

Testing is the process of analyzing a software item to detect the differences between
existing and required conditions and to evaluate the features of the software item.
Test plan components include:
Purpose of Testing
To check the functionality of the system:
Items to be tested:
Interface
Code
Features to be tested:
Reliability
Performance
Reusability
Management and Technical approach:

System will undergo unit testing and functional testing first.
After the changes are made, regression testing will be done.
Integration testing will take place only after thorough unit and component testing
Interface testing will be done for the project. Performance testing will be done to check and

improve performance and usability of the solution.
5.2 Test Items
5.2.1 Scope
Testing will be involved at several points in the life cycle as the project is constructed.
Testing is a very ‘dependent’ activity. As a result, test planning is a continuing activity
performed throughout the system development cycle.
The test scope included:
 Performing functional testing of the various modules of the system.
 Performing limited functional testing after integration of both major modules.
 Fast response time for overall process of the system to increase the efficiency and
effectiveness of the system should be tested.
 Feedback and storage of images and strategies for accuracy, consistency, clarity and
usability for testing and ensuring proper working of system.
 Verifying defined processes, functionality, and sequencing.
 Performance or scalability testing
5.2.2 Reference Material

Project Synopsis
Concept document
Software Requirement Specification (SRS)
Project Plan
IEEE Software Test Plan
Relevant UML Diagrams
User Manual
5.2.3 Test Items
Following are the test items:
Code
Interfaces

Program module
Following program modules will be tested:
Input database
Image to IP module
Co-ordinates to AI module
Strategies and moves with co-ordinates to GUI module.
Operator Procedures
When the coding of the software to be developed is finished, the system will be
given to the testing team for testing. For that purpose, the system will be first installed to
check whether it works properly in the given environmental conditions. Those conditions
could be like, hardware configuration e.g. speeds of RAM for faster processing, and does
the system work for different versions of WINDOWS.
5.2.4 Testing Process
Test Deliverables
Here, for unit testing, each and every unit on the module will be tested for
different inputs. All this will be analyzed on which testing is done, prerequisite,
objective, steps and data and further action if there, would be made.
In case of integration testing the similar analysis for testing are prerequisite, test
case description, steps and data, expected result actual results and pass-fail.
Defect report will be generated once the testing is finished. Defect report
generally contains failures or the faults in the system.
Testing Tasks
For starting with testing task, system must be properly installed.

Responsibilities
Programmers of the software do all the testing. So, they will record the test cases.
Resources
For testing purpose, different resources like software and hardware resources will
be required.
5.2.5 Environmental Requirements
Software Requirement
Storing of the test reports will be done in text file or some data storage like Excel
sheet, etc.
Risks and Assumptions

It is assumed that the testing process will follow the schedule as planned.
Change management procedure

If the process is getting delayed, respective faculty will approve those changes
and accordingly further testing process will be changed.

5.3 TEST PLAN
5.3.1 Introduction
Nature of the project
FRVS is basically a biometric application used to identify valid voters. It avoids

malpractices at voting centers by recognizing faces of voters and fetch information whether he or
she is valid or not.
GUI is constructed so neatly that it will be a user friendly for new user. GUI has all the
provisions for new user to know about whole application.
Testing is done in all perspectives to know user friendliness of the application and system
compatibility in all aspects of programming environment.
System test objective and scope:
The objective of testing of IDE is that
• IDE is working according to requirement specification.
• Software meets performance requirements.
• Software is reliable and robust and it can recover gracefully from failure.
• Software ids easy to use and maintain.
• Software is secured.

5.1 ACCEPTANCE TEST :

Name of Test Case Test Case Description Expected output Remark
Validate 1.Invalid username 1.It will not execute SUCCESSFUL.

Administrator or/and password any operation.
2.Valid username and 2.Access to system

password will be allowed. SUCCESSFUL.
Validate attributes 1.Invalid inputs for 1.Returns as invalid SUCCESSFUL.

for adding voter name, city, dob, phone information
number
2.Valid inputs for 2.Voter is added SUCCESSFUL.

name, city, dob, phone
number
5.2 CODE BASED TESTING:

We have adopted a control flow based approach for code based testing here. Various test
case are designed for different modules and code based testing is performed.
5.2.1 Test cases for adding voter

Test case 1(Normal)
{
Specify valid username and password.
Specify valid name, place, phone number and date of birth.
}

Code Paths covered: database feed

Result: Successful.
Test case 2(Invalid details specified)

{
Give error prompt.
Redirect user to specify valid details
}
Code Paths covered: database feed

Result: Successful.
5.2.2 Test cases for image browser

Test case 1(Normal)
{
Specify images for voter
Write all useful information like name, place, phone number and date of birth.
}
Code Paths covered: image browser

Result: Successful.
Test case 2(Voter not specified)

{
Give error prompt.
Redirect user to specify voter.
}
Code Paths covered: image browser

Result: Successful.
5.2.2 Test cases for image handler

Test case 1(Normal)
{
Specify start for video.
Specify stop for video.
Specify option as face detection.
Give result
Code Paths covered: image processor

Result: Successful.
Test case 2(Invalid option selected)

{
Give error prompt.
Redirect user to specify valid option
}
Code Paths covered: image processor

Result: Successful.
5.2.2 Test cases for face recognizer

Test case 1(Normal)
{
Specify target image
Specify option as face recognition

Give result
Code Paths covered: face recognizer

Result: Successful.
Test case 2( Target image not specified)
{
Give error prompt.
Redirect user to specify target image
}
Code Paths covered: face recognizer

Result: Successful.

5.3. BRANCH TESTING:

Inputs to the Branch taken Expected Outcome Remark
component
Enter the login 1: If the login name 1: If the login name and SUCCESSFUL
name and and password is password is correct then
password for correct then respected command
administrator respected command function is invoked.
function is invoked.
2: Else Error handler 2: Else Error handler is SUCCESSFUL
is invoked. invoked.
Enter command Error handler Error handler invoked SUCCESSFUL
without login invoked
name and
password
Enter incomplete Corresponding Corresponding SUCCESSFUL
information in procedure for procedure for executing
voter registration. executing that that commands is
commands is invoked
invoked
Delete voter from Corresponding Corresponding SUCCESSFUL

manage share procedure for delete procedure for showing
is invoked prompt is invoked
5.4 COMPONENT TESTING:
It refers to the testing of individual software components. A nontrivial, nearly

independent and replaceable part of a system that fulfills a clear function in the context of well
defined architecture. A component conforms to and provides the physical realization of a set of

interfaces.
The testing has processed in the form of following 3 types of tests:
5.4.1: Function testing:
No Module Input Function Output Remark

name
1 Face detector Captured Detection of Detected SUCCESSFUL

video faces faces
2 Image Detected Processing of Discrete SUCCESSFUL

processor faces image grids of
image
3 Face Target image Comparison of Retrieve SUCCESSFUL

recognizer target image details from
with source database
images in
database
5.4.2: Structural testing:

The structural testing has been carried out by base lining the acceptance testing, code
based testing and branch testing. This testing applied to several components further followed by
interaction testing.
Test result: Successful.

5.4.3: Interaction and Integration testing:
The interaction testing has been carried out by checking whether each module is getting correct

input or not from interaction with previous module and whether it gives correct output to the next
desired module. Interaction and Integration testing checks proper communication between
modules.
No. Module Name Input / Module Output / Module Remark

from which to which output is
input is given given
1 Face detector Capture Video Image processor SUCCESSFUL
2 Image Face detector Face recognizer SUCCESSFUL

processor
3 Face recognizer Face detector Recognition SUCCESSFUL

and image
processor

Chapter 6.
Result and Discussion
Our project is meant for improving our voting system with the help computer
vision and Bio-informatics.
In order to do this we created a database of all voters along with their

photographs. After processing these photographs descriptors are created which are stored
in a XML file. When a voter’s image is captured at the election booth, same processing
will be done on the image and its descriptors will be created. Now the descriptors of this
image is compared with the descriptors of images stored in the database. It will try to find
a match for the target image.
So in order to achieve above thing we are going to make use of following

techniques:

4. Face Detection using OpenCv.
5. Segmentation using RGB technique.
6. Indexing
For a large country, managing the data of every citizen is a cumbersome job. In
such a country if identification of voters is done by a human being, it’s definitely going to
enforce many human errors. So what if the job is done by a tireless computer system.
Our project provides you with a almost error-free enviornment. And only a valid voter
whose registration is done with the government database will be allowed to cast a vote.
This project can be enhanced to a greater extent with the help of internet. We have
restricted our project to a single booth. But if a centralized database system is managed it
will allow voter to vote for his area candidate from any booth.

Chapter 7.
Conclusion
Thus, we have implemented our project named as Face Recognition for voting
system, which provides an alternative and an efficient way for a current voting system
with the help of computer vision and Bio-informatics.
Our system provides a way to identify a voter with the help of face detection and
face recognition techniques.
We also provide a fast image matching technique with the help of indexing.

References.

C#complete Reference – Herbert Schildt
Digital image processing – Gonzalez Woods
Digital image processing and analysis – Chanda Majumdar
Digital signal and image processing – Bose

Final Report Partial

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Final Report Partial

Diunggah oleh

Hak Cipta:

Format Tersedia

Face Recognition Group No:

S.C.O.E. Dept of Information Technology 1 Year 2009-10

Face Recognition for voting system provides a computerized approach for

S.C.O.E. Dept of Information Technology 2 Year 2009-10

1. Face Detection using OpenCv.

2. Segmentation using RGB technique.

1.2 BACKGROUND AND BASICS

1.3 LITERATURE SURVEY

S.C.O.E. Dept of Information Technology 3 Year 2009-10

1.3.2 RGB Technique

S.C.O.E. Dept of Information Technology 4 Year 2009-10

1.3.3 .NET FRAMEWORK:

The Microsoft .NET Framework is a software framework available with several

S.C.O.E. Dept of Information Technology 5 Year 2009-10

PRINCIPLES DESIGN FEATURES:

Common Runtime Engine

S.C.O.E. Dept of Information Technology 6 Year 2009-10

Base Class Library

S.C.O.E. Dept of Information Technology 7 Year 2009-10

Visual overview of the Common Language Infrastructure (CLI)

S.C.O.E. Dept of Information Technology 8 Year 2009-10

The intermediate CIL code is housed in .NET assemblies. As mandated by

S.C.O.E. Dept of Information Technology 9 Year 2009-10

.NET Framework uses appdomains as a mechanism for isolating code running in

S.C.O.E. Dept of Information Technology 10 Year 2009-10

Namespaces in the BCL[9]

The .NET Framework includes a set of standard class libraries. The

S.C.O.E. Dept of Information Technology 11 Year 2009-10

APIs are part of either System.* or Microsoft.* namespaces. These

The Framework Class Library (FCL) is a superset of the BCL classes

S.C.O.E. Dept of Information Technology 12 Year 2009-10

memory management itself. To this end, the memory allocated to

The .NET Garbage Collector (GC) is a non-deterministic, compacting,

S.C.O.E. Dept of Information Technology 13 Year 2009-10

Since the memory held by garbage is not of any consequence, it is

The GC used by .NET Framework is actually generational. Objects

S.C.O.E. Dept of Information Technology 14 Year 2009-10

1. Sponsor Status : INHOUSE

• Problem: Provide a means to detect fraud voters by

- Maintaining Voter image database

- Detecting the real time voter image using a camera

- Comparing Current voter image with the stored images.

1.4.2. SOFTWARE REQUIRENMENT SPECIFICATION:

1.1) PROBLEM STATEMENT

This product helps to avoid malpractices carried out at voting center.

The modules namely Image processor and Face Recognizer can be

S.C.O.E. Dept of Information Technology 15 Year 2009-10

checking at exam centers etc.

There are various algorithms exist for face recognition. Earlier

System Overview: The SRS contains the problem statement, summary of

S.C.O.E. Dept of Information Technology 16 Year 2009-10

1.4.2.3) Project Status: -

Object oriented concepts are used while coding and documentation

Sr.No Requirement Priority Expected Result

S.C.O.E. Dept of Information Technology 17 Year 2009-10

a) Manage Voter Details,

S.C.O.E. Dept of Information Technology 18 Year 2009-10

S.C.O.E. Dept of Information Technology 19 Year 2009-10

2.1 Project Planning And Management

S.C.O.E. Dept of Information Technology 20 Year 2009-10

2.1.1 Incremental Software Development Model

2.2 Feasibility Study

S.C.O.E. Dept of Information Technology 21 Year 2009-10