OFFLINE HANDWRITTEN SIGNATURE VERIFICATION SYSTEM USING SIFT FEATURES A Project Report Submitted in Partial Fulfillment of the Requirements for the Degree of Bachelor of Engineering in Computer Engineering Submitted by Saurabh Kohok Shweta Wani Manish Mahajan Madhavi Patil DEPARTMENT OF COMPUTER ENGINEERING SSVPS’s B. S. DEORE COLLEGE OF ENGINEERING, DHULE 2011 - 2012
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
OFFLINE HANDWRITTEN SIGNATUREVERIFICATION SYSTEM USING SIFT
FEATURES
A Project Report Submitted
in Partial Fulfillment of the Requirements
for the Degree of
Bachelor of Engineering
in
Computer Engineering
Submitted by
Saurabh KohokShweta Wani
Manish Mahajan
Madhavi Patil
DEPARTMENT OF COMPUTER ENGINEERING
SSVPS’s B. S. DEORE COLLEGE OF ENGINEERING, DHULE2011 - 2012
OFFLINE HANDWRITTEN SIGNATUREVERIFICATION SYSTEM USING SIFT
FEATURES
A Project Report Submitted
in Partial Fulfillment of the Requirements
for the Degree of
Bachelor of Engineering
in
Computer Engineering
Submitted by
Saurabh KohokShweta Wani
Manish Mahajan
Madhavi Patil
Guided by
R.V.Patil
DEPARTMENT OF COMPUTER ENGINEERING
SSVPS’s B. S. DEORE COLLEGE OF ENGINEERING, DHULE2011 - 2012
SSVPS’s B. S. DEORE COLLEGE OF ENGINEERING, DHULE
DEPARTMENT OF COMPUTER ENGINEERING
CERTIFICATE
This is to certify that the Project entitled OFFLINE HANDWRITTEN SIGNATURE
VERIFICATION SYSTEM USING SIFT FEATURES has been carried out by
Saurabh KohokShweta Wani
Manish Mahajan
Madhavi Patil
under my guidance in partial fulfillment of the degree of Bachelor of Engineering in
Computer Engineering of North Maharashtra University, Jalgaon during the academic
year 2011 - 2012. To the best of my knowledge and belief this work has not been
submitted elsewhere for the award of any other degree.
Date: April 27, 2012
Place: Dhule
Guide
R.V.Patil
Head Principal
G. K. Patnaik Dr. Hitendra D. Patil
iii
Acknowledgement
We express true sense of gratitude towards our guide Mr.R.V.Patil for his valuable co-
operation and guidance that he gave us at every stage of our project. We would also like to
thank to our head of department Mr.G.K.Patnaik for permitting us to undergo this project,
inspiring us and providing all the facilities, which made this project work very convenient.
We also express our thanks and our sincere gratitude towards our parents who provided us
a launch pad and because of that we are at level of our carrier.
Saurabh Kohok
Shweta Wani
Manish Mahajan
Madhavi Patil
iv
Contents
Acknowledgement iv
Abstract 1
1 Introduction 2
1.1 Need of the System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Problem Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Basic of Signature Verification System . . . . . . . . . . . . . . . . . . . . . 3
1.4 Organization of Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Analysis 5
2.1 Requirement Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 User Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Feasibility study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Team Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3 Design 7
3.1 Software Requirement Specification . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Hardware Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3 Risk Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4 System Modeling 11
4.1 Flow chart for proposed methodology . . . . . . . . . . . . . . . . . . . . . . 11
4.2 UML diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.1 Use Case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.2 Sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
v
5 Signature Verification System 14
5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2 Levels of Forgery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.3 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6 Coding 17
6.1 Data Acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2 Pre-Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.3 Extraction of SIFT Features . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.4 Calculation of Euclidean Distance . . . . . . . . . . . . . . . . . . . . . . . . 19
6.5 SIFT Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.5.1 Scale-Space extreme a detection . . . . . . . . . . . . . . . . . . . . . 19
6.5.2 Accurate key point localization . . . . . . . . . . . . . . . . . . . . . 20
6.5.3 Orientation Assignment . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.5.4 Keypoint Description . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7 Testing 23
7.1 Formal Technical Reviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.2 Test Cases and Test Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.3 Test Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.3.1 Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.3.2 Regression Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.3.3 System Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.3.4 Alpha Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8 Conclusion 26
Bibliography 27
Index 28
vi
List of Tables
3.1 Performance Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Project Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Technical Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1 Testing Table for input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
vii
List of Figures
1.1 Methodology[2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1 Flowchart for HSV methodology . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2 Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1 Levels of Forgery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1 Signature Data Acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2 Sample of Space Scale Gaussian images . . . . . . . . . . . . . . . . . . . . . 18
6.3 Steps in Signature Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.4 Difference -of- Gaussian computation[2] . . . . . . . . . . . . . . . . . . . . . 20
6.5 Scale Space Extrema Detection[2] . . . . . . . . . . . . . . . . . . . . . . . . 21
viii
Abstract
In this project we evaluate the use of SIFT (Scale Invariant Feature Transform) features in
offline handwritten signature verification. For each known writer we will take a sample of
three genuine signatures and extract their SIFT de-scriptors. To calculate the intra-class
distance(measure of variability within the same author) among SIFT descriptors, Euclidean
distance method can be used. The key points Euclidean distances, the image distances and
the intra class thresholds need to be stored as templates. We can use intra-class distance
thresholds like the maximum, average, minimum and range. The intra-class threshold is will
be compared to the inter-class threshold for the claimed signature to be considered a forgery.
1
Chapter 1
Introduction
The handwritten signature is the popular means of authentication. Every person has dif-
ferent signature. It will be extremely useful when an electronic device can display at least
the same virtuosity. The development of computer-aided handwritten signature verification
systems has been ongoing for decades. Different approaches are developed to deal with the
handwritten signature recognition problem.
The chapter is organized as follows. Section 1.1 Need of the system. Section 1.2 Problem
definition. Section 1.3 Basic of signature verification system. Section 1.4 Organization of
the report.
1.1 Need of the System
Offline handwritten signature system are used by various stockholders to provide efficient
and economical state of the system. The main purpose of signature verification systems is
to differentiate between original and forged signatures, which are related to intra-personal
and inter-personal variability. Intra-personal variation is variation among the signatures of
the same person and inter-personal is the variation between the originals and the forgeries.
1.2 Problem Definition
Most of the available offline handwritten signature verification methods do not cater for
scale and rotation variation. The Scale Invariant Feature Transform (SIFT) is an image
processing algorithm that takes an image and transforms into a collection of local feature
vector. The SIFT algorithm has proved to be efficient in both recognition and verification
problems.Fraud, especially handwritten signature forgery, is rampant across all sectors of the
economy. Despite this there is no economical and reliable automated handwritten signature
verification system available.
2
CHAPTER 1. INTRODUCTION
1.3 Basic of Signature Verification System
Handwritten signature verification has been extensively studied and implemented. Its many
applications include banking, credit card validation, security systems etc. In general, hand-
written signature verification can be categorized into two kinds - on-line verification and
off-line verification. As shown in figure 1.1 on-line verification requires a stylus and an
electronic tablet connected to a computer to grab dynamic signature information. Off-line
verification, on the other hand, deals with signature information which is in a static format.
In off-line signature recognition we are having the signature template coming from an imag-
ing device, hence we have only static characteristic of the signatures. The person need not
be present at the time of verification. Hence off-line signature verification is convenient in
various situations like document verification, banking transactions etc[1].
Figure 1.1: Methodology[2]
3
CHAPTER 1. INTRODUCTION
1.4 Organization of Report
The report is organized in a way to cover all important points that are required to make this
report a self exploratory one. This report is divided into following session:
1. The chapter entitled introduction briefly describes the system
2. The chapter analysis, analyze the requirement if the system
3. The chapter design contains various risk related to our system
4. The chapter entitled system modeling, represents the system is modeled in unified
modeling language
5. In the testing part the test cases and their obtained results are documented
6. The report ends with the conclusion and reference
In the analysis and Design phase, we start with analysis and requirement gathering followed
by designing. The system is modeled in Unified Modeling Language(UML).
1.5 Summary
In this chapter, we have seen the introduction of need of the system and how it is beneficial
in various fields. Next chapter gives the detail description of analysis of system.
4
Chapter 2
Analysis
The most important and essential phase of software development is a collection of information
regarding what is the functionality and interface desired in the system. It enables the system
engineer to specify software function and performance indicate softwares interface with other
system elements and establish design constraint that the software must meet.
This chapter discusses the requirement analysis and team structure of the project. Sec-
tion 2.1 describes about the users necessary and desirable requirements. Section 2.2 specifies
the team members of the project.
2.1 Requirement Analysis
Requirement analysis bridges the gap between system engineering and software design. Re-
quirement analysis is the most important task in software development life cycle. Require-
ment analysis allows the software engineering to define the software allocation and build
models of the process, data and behavioral domains that would be treated by the software.
Finally, the requirement specification provides the developer and customer with the means
to assess quality ones the software is built.
2.1.1 User Requirement
Necessary Requirements
• There should be scope for future extension
• Easy Updating
• It has reasonable cost
• No viruses to be loaded along with the software
• User friendly/Interactive
5
CHAPTER 2. ANALYSIS
Desirable Requirements
• Easy installation,updating and usage of software
• Facility to support all resolutions
• It should be windows based
• Affordable
2.1.2 Feasibility study
All the projects are feasible if unlimited resources and unlimited time is given.Practically,
it is not possible to provide unlimited resources and unlimited time to any project. The
development of computer based system is more likely to be affected by lack of resources and
time deadlines.
2.2 Team Structure
The team members are:
Saurabh Kohok
Shweta Wani
Manish Mahajan
Madhavi Patil
2.3 Summary
In this chapter, an overview of the software allocation and build models of the process and
specified software functions with its specification is provided. In the next chapter, gives the
detailed description of system elaboration.
6
Chapter 3
Design
Design specifies hardware and software specification and various risk associated with the
system.
This chapter describes about software requirement specification, hardware requirement
specification, risk assessment. Section 3.1 describes what software we require for our system.
Section 3.2 describes what hardware do we require for our system. Section 3.3 describes
what risk are involve in the software.
3.1 Software Requirement Specification
Both the software developer and customer conduct review of software requirement specifi-
cation. The review is first conducted at macroscopic level and then detailed level. Once the
review is completed, Both Customer and developer sign off a software requirement specifi-
cation. The specification becomes a contract for software development.
Operating System:- Windows XP/2000
Platform:- MATLAB
3.2 Hardware Specification
• Main Processor: Intel Pentium IV
• RAM: 1 GB DDR2-RAM
• Motherboard : 945GSM Intel Chipset
• Scanner
• Disk space : 3.73 GB Disk Space for MATLAB R2010a
7
CHAPTER 3. DESIGN
3.3 Risk Assessment
Before embarking on the project, it is necessary to review at the risks that might be involved
in it. These risks have been documented as seen before the coding for the project was sorted.
Majority of the risk components lie under the following categories.
1. Performance Risk
2. Project Risk
3. Technical Risk
Performance Risk:
Is the degree of uncertainty that the product will meet. Its requirement will be fit for its
intended use. Table 3.1 describes about performance risk according to criticality of the
various aspect of the performance.
Table 3.1: Performance Risk
Sr.No RISK Likehood Impact
1 Will the product not meetthe specified standards?
Low Critical
2 Will the software generateschedule correctly?
Very Low Critical
3 Will the software degradethe performance of theclients system?
Low Critical
4 Will the software have de-fects after release?
Low Catastrophic
Project Risk:
Threaten the project plan. That is if project risk becomes real, it is likely that project
schedule will slip and the cost will increase. Project risk identify potential budgetary, sched-
ule, personal(staffing and organization), resource, customer and requirement problem and
their impact on software project. Table 3.2 describes about project risk according to various
critical aspect of our system.
8
CHAPTER 3. DESIGN
Table 3.2: Project Risk
Sr.No RISK Likehood Impact
1 Will the project over-shootpredefine deadlines?
Low Critical
2 Will resources for de-velopment of project bescarce(e.g. H/W lock)
Low Critical
3 Will customer requirementsremain constant throughoutthe development of project?
Low Critical
Technical Risk:
Threaten the quality and timeliness of the software to be produced. If the technical risk
becomes a reality, implementation become difficult or impossible. Technical risk identify
potential design, implementation, interface, verification and maintenance problem. In ad-
dition, specification ambiguity, technical uncertainty and leading edge technology are also
risk factors. Technical risk occurs because the problem is harder to solve then we thought it
would be. Table 3.3 describes about technical risk of assessing.
Table 3.3: Technical Risk
Sr.No RISK Likehood Impact
1 Is support material forthe development of projectavailable(Research papers,Documents of similarsoftware etc.)?
Low Catastrophic
2 Are the developers inca-pable of developing the sys-tem?
Low Catastrophic
3 Will the system be futurecompliant?
High Negligible
4 Is the existing technologyis incapable of providing abase to develop this soft-ware?
Low Catastrophic
9
CHAPTER 3. DESIGN
3.4 Summary
What are the needed software and hardware for the system is given in the this chapter. It
also describes the risk that would may cause in this system. Next chapter gives the detail
description on system modeling.
10
Chapter 4
System Modeling
A model has both semantics and notations and can take various forms that include both
pictures and tests. The model is intended to be easier to use for certain purposes then
final system. The model of software system is made in a modeling language called Unified
Modeling language UML. Visualizing, Specifying, Constructing and Documenting object
oriented system is exactly the purpose of UML.
In this chapter, section 4.1 Flow Chart for proposed methodology. Section 4.2 UML
diagrams which represents the behaviour of the system and proposed methodology represents
flow of the system.
4.1 Flow chart for proposed methodology
Figure 4.1: Flowchart for HSV methodology
Figure 4.1 represents that system get the claim signature from user and extract all SIFT
11
CHAPTER 4. SYSTEM MODELING
features and comparison is done between claimed signature and sample signature stored in
the database. After comparison output is given displaying decision whether the signature is
genuine or forged one.
4.2 UML diagrams
A diagram is a set of graphical representation of a set of arcs. Diagrams have been developed
in UML.
4.2.1 Use Case diagram
Use case diagram represents the overall scenario of the system. A scenario is nothing but a
sequence of steps describing an interaction between a User and system. Figure 4.2 represents
that user gives sample signatures to system which is stored in the database and whenever
needed claimed signature is given to system by user and then comparison is done between
both claim and sample signature and result is displayed by the system.
Figure 4.2: Use Case Diagram
12
CHAPTER 4. SYSTEM MODELING
4.2.2 Sequence diagram
Sequence diagram shows the workflow or sequential execution of our system
Figure 4.3: Sequence Diagram
Figure 4.3 represent that initially user gives three sample signatures to the terminal
which extracts SIFT features from given sample signatures and then finally that signatures
are stored in the database server. Whenever required user gives claim signature to system.
Claim signature is converted into greyscale and SIFT features are extracted. Signature
verification process begin between claim and sample signature and finally result is displayed.
4.3 Summary
In this chapter, an overview of the system is represented by UML Diagrams. Next chapter
describes the signature verification system.
13
Chapter 5
Signature Verification System
A handwritten signature can be defined as the scripted name or legal mark of an individ-
ual,executed by hand for the purpose of authenticating writing in a permanent form. The
signing act with a writing or marking instrument such as a pen or stylus is sealed on the
paper. The scripted name or legal mark, is applied on paper, may also be accomplished
using other devices that capture the signature process in digital format.
The chapter addresses the overview of the signature verification system . Section 5.1
represents between the difference between the original and the forged signature. And the
later section 5.2 discusses the various levels of forgery section 5.3 specifies its application
5.1 Overview
Hand written signature verification systems are used for forgery detection as they are cheap
and non-intrusive. A direct link between the writer’s identity and the transaction is provided
by them. The objective of signature verification systems is to differentiate between original
and forged signature. Their are two types of variability intra-personal and inter-personal
variability. Intra-personal variation is variation among the signatures of the same person and
inter-personal is the variation between the originals and the forgeries. Their is a difference
between signature recognition and signature verification. Verification decides whether a claim
that a particular signature belong to a specific writer is true or false where as recognition
decides to which of a certain number of writers a particular signature belongs. Automatic
HSV systems are classified into two: offline HSV and online HSV. The online signature is
captured using a special pen called a stylus and digitizing tablet and analysis is based on
dynamic characteristics like pressure, velocity, acceleration and capture time of each point
on the signature trajectory. In offline systems the static image is a input that is scanned
and used for analysis. Both offline and online systems are used to detect various types of
forgeries[3].
14
CHAPTER 5. SIGNATURE VERIFICATION SYSTEM
5.2 Levels of Forgery
1. Random/simple or zero effect: In this the forger does not have the exact shape
of the writer’s signature but can scribble the writers signature. He may find this from
the writer’s name. This type of forgery accounts for majority of forgery cases though
it’s easy to detect with naked eyes.
2. Unskilled or casual Forgery: The fraudulent person knows the writers signature
shape,style and tries to copy it without much practice.
3. Skilled Forgery: This is where the forger has complete access to original signature
model and comes up with a duplicate sample.
The skilled forgery category is further classified into amateur and professional forgery.
A professional forgery is done by a person who is expert in handwriting analysis and
is able to come up with high quality forgery[1].
Figure 5.1: Levels of Forgery
The amateur forgeries are subcategories in the context of online verification into home-
improved and over-the-shoulder forgeries. Home-improved forgeries is the one when the
forger has a copy of the signature and has ample time to practice it. The imitation is based
on static features of the image. Over-the shoulder forgeries are produced when immediately
the forger has seen the writer make a genuine signature. The fraudulent person in this case
has dynamic properties of signature and spatial image.
5.3 Applications
Signature Verification system is implemented in situations where input or written processes
are already in place. These application includes:
• Contract Execution
15
CHAPTER 5. SIGNATURE VERIFICATION SYSTEM
• Formal arguments
• Acknowledgement of services received
• Access to important documents
• Banks
5.4 Summary
The above have chapter represented the different levels of forgery and the application of the
system. Next chapter gives the detail description of system working.
16
Chapter 6
Coding
In this system, a user writes his signature on a piece of paper. This signature is then digitized
through a optical scanner and the biometric system recognizes the signature by analyzing its
shape. The static Information derived from the signatures is used for matching and decision
making.
The Chapter-6 has four sections namely section 6.1Data Acquisition. Section 6.2 Pre-
processing. Section 6.3Extraction of SIFT features from Signatures. Section 6.4Calculation
of Euclidean distance between images which gives the detail description of working of system.
Section 6.5SIFT Related Work process of SIFT extraction.
6.1 Data Acquisition
Data acquisition is the first step in the design of a static signature verification system. Hand-
written signatures are obtained from different individuals. Unique features are extracted from
them to create a knowledge base for each individual. These stored features are then learned
by the system and used as a reference for comparing with those of the test signature in the
recognition phase. For calculating the performance of the signature verification system a
standard database of signature samples is thus needed.
17
CHAPTER 6. CODING
Figure 6.1: Signature Data Acquisition
6.2 Pre-Processing
In this module the signature images are scanned during the data acquisition phase are ex-
tracted and preprocessed. Signature images were stored in portable network graphic (PNG)
format. These images were converted to greyscale for further processing.
6.3 Extraction of SIFT Features
This involves identifying stable shape descriptors from the pre processed signature image.
The implementation used for extracting SIFT features was adopted from a MATLAB func-
tion written by El-Maraghi.
Figure 6.2: Sample of Space Scale Gaussian images
18
CHAPTER 6. CODING
6.4 Calculation of Euclidean Distance
This involved calculation of the Euclidean distances between the SIFT features of two given
signature images to measure the variability between them. Say we have two signatures A
and B. Let Ai be the ith keypoint in signature A and Bj be the jth keypoint in signature B.
The distance D(Ai,Bj ) was calculated as the Euclidean distance between Ai and Bj. Ka,
Kb are the number of keypoints in signature A and B respectively. The distance measure
D( Ai,B) was taken as the average Euclidean distance from the ith keypoint in signature A
to all the keypoints of signature B. The image distance between signature A and signature
B is given by :
Figure 6.3: Steps in Signature Enrollment
6.5 SIFT Related Work
Scale Invariant Features Transform (SIFT) is used to extract distinctive invariant features
from images. The SIFT algorithm is robust for identifying stable key locations in the scale-
space of a grey scale image. It uses the following four steps to extract the set of descriptors
from a given image [2]. 6.5.1 Scale-Space extreme a detection. 6.5.2 Accurate Keypoint
localisation. 6.5.3 Orientation assignment. 6.5.4 Keypoint description.
6.5.1 Scale-Space extreme a detection
Involves searching over all scales and location of the signature image to detect key points
of all sizes. This is done using a difference-of-Gaussian (DoG) function to identify potential
interest points that are invariant to scale and orientation. Difference of Gaussian Function:-
L(x, y, α) = G(x, y, α) ∗ I(x, y) (6.1)
Where * is Convolution in the x and y directions
G(x, y, α) = [(1/(2Πα))exp(−(x+ y/2α))] (6.2)
19
CHAPTER 6. CODING
Difference between 2 nearby scales,D(x,y,α),separated by constants Multiplicative factor k
is given by
D(x, y, α) = (G(x, y, kα) −G(x, y, α)) ∗ I(x, y) = L(x, y, kα) − L(x, y, α) (6.3)
Figure 6.4: Difference -of- Gaussian computation[2]
The keypoints are identified as local maxima and minima of the DoG signature images
across scale. Each pixel in the DoG is compared to other 8 neighbouring pixels at the same
scale and 9 corresponding neighbours at the neighbouring scales. If the keypoint is the
maxima or minima, it is selected as a candidate keypoint. Figure 6.4 illustrates detecting
the maxima and minima of difference-of-Gaussian in scale space[3].
6.5.2 Accurate key point localization
For each candidate key point identified, the interpolation of nearby data is used to accurately
determine its point. Keypoints with low contrast (sensitive to noise) are dropped together
with the responses poorly localised along the edges[3].
6.5.3 Orientation Assignment
Each key point is assigned one or more orientations based on local image gradients direc-
tions. To determine keypoint orientation, a gradient orientation histogram is computed
in the neighborhood of the keypoint using the Gaussian image at the closest scale to the
20
CHAPTER 6. CODING
Figure 6.5: Scale Space Extrema Detection[2]
keypoints. The orientation assignment of each keypoint is obtained by computing the gradi-
ent magnitude M(x,y) and orientation Θ(x, y)of the scale space for the scale of that keypoint
M(x, y) = [(k(x+ 1, y) − k(x− 1, y)) − (k(x, y + 1) − k(x, y − 1))] (6.4)
and
θ(x, y) = arctan((k(x, y + 1) − k(x, y − 1))/(k(x+ 1, y) − k(x− 1, y))) (6.5)
All the properties of the keypoint are measured relative to the keypoint orientation. This
caters for rotation invariance[3].
6.5.4 Keypoint Description
Local image gradients are measured at the selected scale in the region around each key
point and transformed into a representation that allows local shape distortion and change
in illumination. When the keypoint orientation is selected, feature descriptors are computed
as a set of orientation histograms on 44 pixel neighborhoods. The orientation histograms
are relative to the keypoint orientation. The orientation data comes from the Gaussian
image closest in scale to the keypoints scale. The contribution of each pixel is weighted
by the gradient magnitude and by a Gaussian with 1.5 times the scale of the keypoint.
Histograms have 8 bins each and each descriptor contains an array of 4 histograms around
the keypoint. This gives a SIFT feature with448=128 values. This vector is normalized to
enhance invariance to illumination[3]. SIFT features have the following advantages compared
to other shape descriptors
1. Distinctiveness-Individual features can be matched to a large database.
2. Quantity -Many features can be generated even for small objects.
21
CHAPTER 6. CODING
3. Efficiency for real time performance.
6.6 Summary
The various steps required for the signature verification system has been discussed in this
chapter. The next chapter specify the testing of the system.
22
Chapter 7
Testing
In this chapter we are going to discuss about various test plan which includes test cases.
Section 7.1 specifies the technical reviews. Section 7.2specifies the test cases done. Sec-
tion 7.3 discusses the various test plans such as unit testing,alpha testing,integration testing.
7.1 Formal Technical Reviews
The team members meet approximately twice a week for formal technical reviews. In each
of the formal technical reviews the guideline followed were:
1. The meeting was planned well in advance and all team members were intimated
2. The project components to be reviewed was decided
3. All the details of the component, they were ready were discussed in details, according
its design and implementation. The workings of the components were checked and
confirms the requirement was started
4. The team took one of the three decisions regarding the component, based on the reviews
5. Accept the component as it is
6. Accept the component with a few change or modification
7. Reject the components entirely and re-implement it
8. In each formal technical review, the points put up in the previous section were followed
up. The formal technical reviews served as a part of the software quality insurance
plan
23
CHAPTER 7. TESTING
7.2 Test Cases and Test Result
• Input verification
Here we want to check whether SIFT database is connected or not.If the database is
not connected the system gives the run time error as assert or cascade.Also if all the
modules are not in the same directory as where the exe file is,the system gives same
error as above.
Table 7.1: Testing Table for input
Sr.No Test Case Result
1 Database connectivity isworking or not
Error is trapped
2 All the modules are loadedor not
Error is trapped
7.3 Test Plan
As already stated we have followed the modular programming approach for coding. These
modules are built in an incremental manner. They are tested individually to check whether
or not they return the desired result. If they are not performing the required job up to the
desired specification then the bugs are to be found out and the final module is tested again.
The final correct modules are then integrated with other modules and again tested.
This testing is called as ”Integration Testing”. After integration, regression testing is
to be performed to ensure that the integration does not introduce new bugs. Finally when
al modules are put together, alpha testing is to be carried out on the entire system.
We have followed this plan and tried to remove all the bugs in the code. The test cases
used and result obtained at end of the testing are given below in the tabular form.
7.3.1 Unit Testing
The installation of the software is satisfactory.
7.3.2 Regression Testing
All the individual modules were tested for their individual test cases. All the modules
performed satisfactorily.
24
CHAPTER 7. TESTING
7.3.3 System Testing
The system performed with no visible performance degradation or system overload at all.
The speed of the system remains unaffected. All other files on the system were also not
affected.The speed of the system is satisfactory because of SIFT algorithm.
7.3.4 Alpha Testing
The whole system was found to be running perfectly when tested on various machines. The
software worked fine and confirmed to the desired behavior.Only the consideration is that
all the modules of project and the SIFT database should be stored in a same directory.
7.4 Summary
The various testing Plans have been discussed in this chapter.The next chapter discusses the
conclusion and future work of the system.
25
Chapter 8
Conclusion
We have successfully implemented signature verification system based on SIFT features
which is capable of comparing two signature images. Image processing is widely used in many
scientific research areas such as biomedicine and pattern recognition.Various algorithms were
studied for signature verification and it was found that SIFT features is the best suited for
the project.The result obtained from this test showed that SIFT features can be used with
Euclidean distances for offline handwritten verifications.Future work of this system could
be inclusion of SIFT features as image descriptors and various distance measures for online
handwritten signature verification problem.
26
Bibliography
[1] V. Bharti and H. B. Kekre, “Offline signature verification systems,” International Journal
of Computer Applications,New York,U.S.A, vol. 1, no. 27, pp. 50–52, 2010.
[2] A. Dhawan and Aditi.R.Ganesan, “Handwritten signature verification,” Project Report,
University of Wisconsin, Madison, pp. 1–34, 2008.
[3] D. Lowe, “Distinctive image features from scale- invariant keypoints,” International Jour-
nal of Computer Vision.Netherlands, vol. 60, no. 2, pp. 91–110, 2004.
27
Index
Applications, 14
Basic of Signature Verification System, 3
Extraction of SIFT Features, 17
Levels of Forgery, 14
Overview, 13
28
Related Documents
