A

PRELIMENARY PROJECT REPORT

ON

BLOOD TYPE DETECTION USING IMAGE

PROCESSING
SUBMITTED TO THE SAVITRIBAI PHULE PUNE UNIVERSITY, PUNE
IN THE PARTIAL FULFILLMENT OF THE REQUIREMENTS
FOR THE AWARD OF THE DEGREE

OF

BACHELOR OF ENGINEERING (COMPUTER ENGINEERING)

SUBMITTED BY

Shubham Bornar Seat No : B150364243

Vivek Joshi Seat No : B150364331

Parth Gujarathi Seat No : B150364306

DEPARTMENT OF COMPUTER ENGINEERING

STES’S SMT KASHIBAI NAVALE COLLEGE OF ENGINEERING

VADGAON BK, OFF SINHAGAD ROAD

SAVITRIBAI PHULE PUNE UNIVERSITY

2018-19
 CERTIFICATE

This is to certify that the project report entitled

BLOOD TYPE DETECTION USING IMAGE PROCESSING

submitted by

Shubham Bornar Seat No : B150364243

Vivek Joshi Seat No : B150364331

Parth Gujarathi Seat No : B150364306

are bonafide student’s of this institute and their work has been carried out
by him/her under the supervision of Prof. R.B.Kale and it is approved for
the partial fulfillment of the requirement of Savitribai Phule Pune Uni-
versity, for the award of the degree of Bachelor of Engineering (Computer
Engineering).

Prof. R. B. Kale Dr. P. N. Mahalle

Guide Head of Department
Department of Computer Engg. Department of Computer Engg.

(Dr. A. V. Deshpande)
Principal,
Smt.Kashibai Navale College of Engineering Pune 41

Place: Pune
Date:
 ACKNOWLEDGEMENT

Our first experience of project has been successfully, thanks to the support staff
of many friends and colleagues with gratitude. We wish to acknowledge all of them;
however, we wish to make special mention of the following

First of all we are thankful of our project guide Prof. R. B. Kale under whose
guideline we were able to complete our project. We will forever remain grateful for
his valuable help and encouragement. We must make special mention of Prof. P. S.
Desai , for his co-operation and assistance in solving a problem. We are wholeheart-
edly thankful to them for giving us their valuable time and attention and providing
us a systematic ways for completing our project in time.

We would like to thank our Dr. P. N. Mahalle and all lab maintenance staff for
providing us assistance in various hardware and software problem encountered during
course of our project. We would like to thank our friends for listening to the ideas,
asking questions and providing suggestions for improving ideas and also for their help.

We will fail in our duty if we wont acknowledge a great sense of gratitude to the
Principal Dr. A. V. Deshpande and the entire staff members in Computer Engi-
neering department for their co-operation.

Shubham Bornar Seat No : B150364243

Vivek Joshi Seat No : B150364331

Parth Gujarathi Seat No : B150364306

i
 ABSTRACT

Determination of blood type is mandatory before blood donation or blood trans-

fusion in case of emergency situations like accident, some fatal disease. Even today
where there is so much advancement in medical field, blood group detection is still
carried out manually by lab technicians or pathologists. In such case the blood sample
is handled by pathologists and there are many such blood samples, it is monotonous
to do testing and may lead to human errors that may pose risk to the life of an indi-
vidual.

The proposed system aims to develop an embedded system which uses Image Pro-
cessing algorithm to perform tests based on ABO and Rh blood Typing system. In
addition to this very rare blood groups named as Bombay phenotype and acquired
B-negative can also be detected using this system accurately with the help of Antigen,
which is not possible using manual method. The proposed system helps in reducing
human intervention and perform complete test autonomously from capturing the im-
ages of blood sample to final generation of result. The results are also stored for
future references.

Thus, the transfusion based on the principal of the universal donor, reducing trans-
fusion reaction risks and storage of results without human errors.

ii
 List of Abbreviation

ABBREVIATION FULL FORM

UI User Interface

OO Object Oriented

DFD Data Flow Diagram

ERD Entity Relationship Diagram

SDLC Software Development Life Cycle

SRS Software Requirement Specification

iii
List of Figures

3.1 SDLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Agile Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.2 DFD 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3 DFD 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4 ERD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.5 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.6 Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.7 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.8 Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.1 Task network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.2 Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.1 LBP Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

8.1 Main Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

8.2 OPEN FORM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.3 Camera Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
8.4 Retrieve Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
8.5 Output Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

iv
List of Tables

2.1 Literature Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

5.1 Risk identify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.2 category of RISK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.3 RMMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.4 TimeLine Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7.1 Test cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

v
Contents

1 INTRODUCTION 1
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Problem Definition and Objectives . . . . . . . . . . . . . . . . . . . 1
1.4 Project Scope and Limitations . . . . . . . . . . . . . . . . . . . . . . 2
1.4.1 Project Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5 Methodologies of Problem Solving . . . . . . . . . . . . . . . . . . . . 2

2 LITERATURE SURVEY 3

3 SOFTWARE REQUIREMENT SPECIFICATION 6

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
3.3 External Interface Requirements . . . . . . . . . . . . . . . . . . . . . 7
3.3.1 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.2 Hardware Interface . . . . . . . . . . . . . . . . . . . . . . 7
3.4 Non Functional Requirements . . . . . . . . . . . . . . . . . . . . . . 7
3.4.1 Performance Requirement . . . . . . . . . . . . . . . . . . 7
3.4.2 Safety Requirements . . . . . . . . . . . . . . . . . . . . . 8
3.4.3 Software Quality Attributes . . . . . . . . . . . . . . . . . 8
3.5 System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5.1 Database Requirements . . . . . . . . . . . . . . . . . . . 9
3.5.2 Software Requirements . . . . . . . . . . . . . . . . . . . . 9
3.5.3 Hardware Requirements . . . . . . . . . . . . . . . . . . . 9
3.6 Analysis Models: SDLC Model To Be Applied . . . . . . . . . . . . . 10

4 SYSTEM DESIGN 12
4.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

vi
 4.2 DFD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.1 DFD 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.2 DFD 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3 Entity Relationship Diagram . . . . . . . . . . . . . . . . . . . . . . . 15
4.4 UML Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4.1 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4.2 Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . 18
4.4.3 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . 19
4.4.4 Use case Diagram . . . . . . . . . . . . . . . . . . . . . . . 20

5 PROJECT PLAN 21
5.1 Project Estimates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1.1 Reconciled Estimates . . . . . . . . . . . . . . . . . . . . . . . 21
5.1.2 Project Resources . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2 Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.2.1 Risk Identification . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2.2 Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.3 Overview of Risk Mitigation,Monitoring,Management . . . . . 28
5.3 Project Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3.1 Project Task Set . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3.2 Task Network . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.3.3 Timeline Chart . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.4 Team Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.4.1 Team Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.4.2 Management reporting and Communication . . . . . . . . . . 39

6 PROJECT IMPLEMENTATION 40
6.1 Overview of Project Modules . . . . . . . . . . . . . . . . . . . . . . 40
6.2 Tools and Technologies Used . . . . . . . . . . . . . . . . . . . . . . . 41
6.3 Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.3.1 LBP Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7 SOFTWARE TESTING 43
7.1 Types of Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

vii
Blood Group Detection Using Image Processing

7.2 Test Cases And Test Result . . . . . . . . . . . . . . . . . . . . . . . 43

8 Result 46
8.1 Screenshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

9 CONCLUSION AND FUTURE WORK 49

10 REFERENCES 50

SKNCOE, Pune. viii Dept. of Computer Engg.

Blood Group Detection Using Image Processing

Chapter 1
INTRODUCTION

1.1 Overview
Rapid and accurate determine of blood types is very important during emergency
situation before administering a blood transfusion. At present the method based on
image recognition technology to quickly determine blood type has been widely used
in the automated blood analyzer. Here , we propose a fast, accurate and robust blood
group judgement method based on the image features of ABO blood group rapid ana-
lyzer. Firstly, the image of the disk region is segmented and identified automatically.
Then, the median filter is used to suppress the noise to get the best approximation
of the original image. Then, the characteristic parameters of ABO blood group are
extracted according to the gray level distribution of the image. Finally, combined
with the agglutination reaction between antigen and antibody, the final blood group
was determined. The experimental results show that this method can quickly and
accurately classify the ABO blood group, and basically meet the requirements of the
automatic rapid blood group analyzer.

According to ABD blood grouping systems, a person can belong to either of fol-
lowing 8 blood groups: A Rh+, A Rh-, B Rh+, B Rh-, AB Rh+, AB Rh-, O Rh+ and
O Rh-. The blood group detection is done in lab by slide test which is a traditional
method. Most of the techniques applied are still based on interaction between antigen
and antibody and subsequent agglutination of RBC(positive result).The agglutination
shows the lack of interaction means negative result. This traditional blood grouping
presents serious drawbacks such as incorrect blood group detection and manual error
such as wrong typing in the report. Hence, it is necessary to develop an automated
system for blood group detection based on the images of blood.

1.2 Motivation
Manual techniques have been developed in recent years for detecting blood type.
These techniques do not provide efficiency and are prone to human errors and requires
that the test should be carried out several times to get accurate results so it is time
consuming as well. For providing better efficiency, we develop an automatic system.

1.3 Problem Definition and Objectives

Automated blood type detection system using Image Processing and GPU. It will be
detected by Image Processing Technique and Pattern matching algorithm. For our
system we are using Support vector machine based histogram classification technique.
To develop an automated system that will consume less time. Which will require
less human intervention. Will give results accurately without any errors. Which

SKNCOE, Pune. 1 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

will be handy and portable. Which can be operated by any person without much
knowledge about medical field. It should be totally automatic.

1.4 Project Scope and Limitations

1.4.1 Project Scope
To develop an automated system that will consume less time. Which will require less
human intervention. Will give results accurately without any errors. Which will be
handy and portable. Which can be operated by any person without much knowledge
about medical field. It should be automatic

1.4.2 Limitations
• Proper connection must be maintained.

• Cannot buy the product directly just view them

1.5 Methodologies of Problem Solving

The proposed system aims to develop an system which uses Image processing algo-
rithm to perform blood tests based on ABO and Rh blood group detection systems.
The input to the system is the blood sample whose images are captured and for-
warded to the image processing algorithm. It uses Local Binary Pattern (LBP) for
classification of image and Chi-Square based Histogram Evaluation. We are doing his-
togram evaluation to achieve more precision and accuracy while identifying whether
the image is agglutinated or nonagglutinated. Therefore, in order for a computer to
be able to process any kind of images, they must be converted into binary form. If the
data is not converted into binary a series of 1s and 0s the computer will simply not
understand it or be able to process it. With the help of camera module we are going
to capture 4, 16-bit images. This 16-bit images are converted into 8-bit images and
finally they are furtherly converted into 2-bit images based on the threshold value
and the output is displayed on the screen which is in binary format. If the image
captures by camera is agglutinated the result showed on output screen will indicate 1
value for that particular images. Similarly, if the image is non-agglutinated the result
displayed on the screen will show 0 value. The image captured by camera is in red
color when the image is processed with the help of LBP algorithm it is converted into
gray-scale image,this grayscale images will be stored.The user details like, name of a
person, his age, and the blood group will also be stored for future reference.

SKNCOE, Pune. 2 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

Chapter 2
LITERATURE SURVEY

“ ABO Blood Group Detection Based on Image Processing Technology”[2],He has

suggested that, The blood group can be detected by using image processing with
method such as measurement of linear primitives and cir- cular primitives, color in-
formation extraction, object segmentation based on niblack, feature extraction, etc.
A fast, accurate and robust blood group judgment method is proposed for the rapid
and accurate identification of blood type in the case of emergency transfusion.
“ Improvement of Accuracy of Human Blood Groups Determination us- ing Image
processing Techniques”[5], He has suggested that, the blood group can be detected by
using image processing using plate method. This method gives the accurate result.
As the applied image processing tech- nique enables determining fast accurately the
blood type of the analyzed samples of blood. Clearing distinct zones in the pixels
intensity of the images are identified, allowing classifying with mathematical basis
quan- tification the agglutination occurrence.
“Determination and Classification of Blood Types using Image Processing Tech-
niques”[1], Determination of the blood types in a short period of time and without
human errors is very much essential. A method is developed based on processing
of images acquired during the slide test. The image processing techniques such as
thresholding and morphological operations are used. The images of the slide test
are obtained from the pathological laboratory are processed and the occurrence of
agglutination are evaluated. Thus the developed automated method determines the
blood type using image processing techniques. The developed method is useful in
emergency situation to determine the blood group without human error.
“ Classification of blood type by microscopic color images”[7]. In this paper,
SVM method was used on microscope images of blood (after adding anti- gens) in
8 categories. This paper discusses the SVM classifier for automatic classification of
eight blood types. Because SVM is based on structural risk minimization principle,
it has high recognition rate and robustness. Such automated classification of blood
types overcomes the drawbacks of the manual blood typing.
“ A Novel approach for Blood Tests based on Image Processing Techniques”[3],
In this paper the simulation using image processing techniques describes the vari-
ous stages in performing the required tasks. Thus the sampled image is processed
and classification model for this automated system will contribute greatly for blood
acquisition especially when there are emer- gency needs for blood transfusion pur-
poses. In future, the work can be extended by enlarging the sample size by using the
same procedure. The analysis of blood samples can be used for finding rare blood
types.Moreover other machine learning techniques can be used comprehensively in
analyzing the model and compare the results.
“ Determination and Classification of Blood Types using Image Processing Tech-
niques”[6], Determination of the blood types in a short period of time and without
human errors is very much essential. A method is developed based on processing
of images acquired during the slide test. The image processing techniques such as

SKNCOE, Pune. 3 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

threshold and morphological operations are used. The images of the slide test are
obtained from the pathological laboratory are processed and the occurrence of agglu-
tination are evaluated. Thus the developed automated method determines the blood
type using image processing techniques.
“ Automated ABO Rh-D Blood Type Detection using Smartphone Imaging for
Point-of-Care Medical Diagnostics”[4], the paper present methodology for automated
ABO Rh-D blood typing using simple morphological im- age processing algorithms
to be used in conjunction with a fabric strip based rapid diagnostic test. Images
of the fabric strip post testing are ac- quired using low cost mobile phones and the
proposed algorithm proceeds to automatically identify the blood type by processing
the images using steps comprising of noise reduction, range filtering and empirically
derived heuristics. The ultimate goal is to provide a simple mobile phone applica- tion
to enable automated, rapid and accessible blood type detection at the point-of-care.
“ Automatic System for Determination of Blood Types Using Image Pro- cessing
Techniques”[8], This work aims to develop an automatic system to perform these
tests in a short period of time, adapting to emergency situa- tions. To do so, it uses
the slide test and image processing techniques using the IMAQ Vision from National
Instruments. The image captured after the slide test is processed and detects the
occurrence of agglutination. Next the classification algorithm determines the blood
type in analysis. Finally, all the information is stored in a database. Thus, the system
allows deter- mining the blood type in an emergency, eliminating transfusions based
on the principle of universal donor and reducing transfusion reactions risks.

SKNCOE, Pune. 4 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

Sr No. Title Technique Used Disadvantage

1 ABO blood group de- Feature extraction Gives accurate result
tection based on im- but time consuming.
age processing tech-
nology(2017)
2 Improvement of Ac- Name plate Requires 30 minutes
curacy of Human which is excessive es-
Blood Groups De- pecially in emergency
termination using situation
Image processing
Techniques(2015)
3 Determination and Morphological pro-
More chances of hu-
Classification of cessing man error are possible
Blood Types using only experts can tell
Image Processing the blood type by see-
Techniques(2018) ing at the agglutina-
tion process.
4 A novel approach to The system first Artificial neural net-
detect blood type performs image work system is used
using image process- pre-processing by his- which is a complex
ing.(2017) togram equalization system.
and color correction
and then a color space
conversion from RGB
to HSI is done
5 Blood type classifi- It uses SVM (Support Microscope images are
cation by microscope Vector Machine) clas- rarely balanced cor-
colour images(2013) sifier which works on rectly hence it requires
structural risk mini- lot of pre-processing
mization principle tasks
6 Blood type detection The image process- The blood and
by image processing ing techniques such as reagents are man-
techniques thresholding and mor- ually introduced in
phological operations slides by the user
are used hence it is not fully
automated(2014).
7 Automatic System The slide test and MORE TIME CON-
For Determination of image processing SUMING
Blood Types Using techniques using the
Image Processing IMAQ Vision from
Techniques(2013) National Instruments.

Table 2.1: Literature Survey

SKNCOE, Pune. 5 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

Chapter 3
SOFTWARE REQUIREMENT SPECIFICATION

A software requirements specification (SRS) is a detailed description of a software sys-

tem to be developed with its functional and non-functional requirements. The SRS
is developed based the agreement between customer and contractors. It may include
the use cases of how user is going to interact with software system. The software
requirement specification document consistent of all necessary requirements required
for project development. To develop the software system we should have clear under-
standing of Software system. To achieve this we need to continuous communication
with customers to gather all requirements.

A good SRS defines the how Software System will interact with all internal mod-
ules, hardware, communication with other programs and human user interactions with
wide range of real life scenarios.

3.1 Introduction
Purpose and scope of the project
Software Requirement Specication is a description of a software system to be de-
veloped, laying out functional and non-functional requirements, and may include may
include set of use cases that describes interactions the users will have with the soft-
ware.

3.2 Functional Requirements

The user can be technician, patient or doctor, who will use system for checking re-
quired blood group. The customer should be able to do the following functions:

• Knowledge of the app: When a user knows how the working and its usage is
going to be, it creates a lot of difference into the persons mind as he demands
for a better perfection ratio and tries to have better results each time.

• Provide the blood sample: The user should able to provide blood sample whose
blood group is to be detected, enter the details like name, age, etc.

• Capture images of blood sample: The system should able to capture images of
blood sample and store it in database for further processing.

• Processing: The system should able to process captured images by removing noise
with help of proper algorithms for accurate detection of blood group.

SKNCOE, Pune. 6 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

3.3 External Interface Requirements

3.3.1 User Interface
• Front end software: Windows Application: An application will be used as in-
terface for user interaction. Application will be designed in Visual Studio

• Back End Software: C++: C++ is a general-purpose object-oriented program-

ming (OOP) language, developed by Bjarne Stroustrup, and is an extension of
the C language.C++ is considered to be an intermediate-level language, as it
encapsulates both high- and low-level language features.

3.3.2 Hardware Interface

• Computer System: The main hardware platform is Computer(including GPU)
with Winodws 10 Operating System installed.

• Camera quality A good qualtity camera for capturing images.

3.4 Non Functional Requirements

Nonfunctional requirements are the properties that your product must have. Think of
these properties as the characteristics or qualities that make the product attractive,
or usable, or fast, or reliable. These properties are not required because they are
fundamental activities of the product activities such as computations, manipulating
data, and so on but are there because the client wants the fundamental activities
to perform in a certain manner. They are not part of the fundamental reason for
the product’s existence, but are needed to make the product perform in the desired
manner.

3.4.1 Performance Requirement

• Scalability: Analytic platform must be applicable to a machine or facility of any
size. The solution must be able to add assets without a need for any incremental
investment in hardware, software or dedicated labor hours.

• Performance: The objective for an industrial analytic platform is to provide the

production facility with accurate and timely data. Targeted performance mea-
surements of the following will need to be defined:

• Correct Alerts (True Positives)

When a system is running it must be seen that the alerts generated by the
application is true. When the system performs true signs then only the output
result can prosper.

• False Alerts (False Positives)

If false data is passed to the user, then problems arise as he interprets those
signals and then gets misguided. So proper value must always be noted.

SKNCOE, Pune. 7 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

• Missed Failures (False Negatives)

When a system failure value is send then it must be seen to follow these paths
or not. When followed wrong system access then the feedback is also wrong.

• Recall
Recall means to have the data called back again to understand the proper mean-
ing of it. When at first the attempt is not understood we can send a signal back
for understanding.

• Precision
The perfect understanding and accurate point to point feedback obtained or
result can be categorized as precision.

• F-score
In statistical analysis of binary classification, the F-score is a measure of a test’s
accuracy. It considers both the precision p and the recall r of the test to compute
the score: p is the number of correct positive results divided by the number of
all positive results returned by the classifier, and r is the number of correct
positive results divided by the number of all relevant samples.

3.4.2 Safety Requirements

If there is extensive damage to a wide portion of the application due to catastrophic
failure, such as a crash, the recovery methodology must be implemented to it. A
special care of no damages must not be to it. A crash can happen anytime but we
as developers must always be ready to have counter measures for it. A proper set
of standards or protocols must be gathered so as whenever problem arises we need
not to wait for long quantum times. Safety should be handled correctly as one step
wrong can make whole system disrupt. To help the application from crashes always
be ready to have set counter measures before and not after. Most AI algorithms are
fuzzy typically learning as they go along. For items that are of critical safety impor-
tance what you want is deterministic. These algorithms are easier to prove correct,
which is essential for many safety critical applications. First it is possible that the AI
will make unpredictable decisions. Granted, they can be beneficial, but when talking
about safety-concerns, you can’t take risks like that, especially if people’s lives are on
the line.

The second is that the “reasoning” behind the decisions can’t always be traced (some-
times there is a random element used for generating results with an AI) and when
something goes wrong, not having the ability to determine “why” (in a very precise
manner) becomes a liability.

In the end, it comes down to accountability and reliability.

3.4.3 Software Quality Attributes

• Correctness: The requirement placed should contain correct description.

SKNCOE, Pune. 8 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

• Reliability: The bidding process should be reliable over the time irrespective rate
of bidding.

• Adequacy: The input required of the user should be limited to only what is nec-
essary.

• Learnability: The user interface should present information as close to reality as

possible and permit efficient utilization of the softwares failures.

• Robustness: Frequent errors (e.g. erroneous commands, typing errors) must be

handled with particular care. Less frequent errors (e.g. power failure) can be
handled more laxly, but still must not lead to irreversible consequences.

• Maintainability: The bidding process should maintain the time of bidding.

• Extensibility: The product should be able to work with extended features.

• Efficiency: The product should work efficiently under heavy workload.

• Availability: The advance enquiry system should be available so bidder can en-
quire for a service before bidding.

• Usability: The customer should be able to specify all his needs.

3.5 System Requirements

3.5.1 Database Requirements
• MS-SQL

3.5.2 Software Requirements

•Visual Studio 2013
• C++
•Windows 10
• Some supporting basic language tools

3.5.3 Hardware Requirements

• 2GB RAM
• Dual core processor with 1.8 GHz frequency
• 4 GB Hard Disk

SKNCOE, Pune. 9 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

3.6 Analysis Models: SDLC Model To Be Applied

Software Development Life Cycle A software development lifecycle is essentially
a series of steps, or phases, that provide a model for the development and lifecy-
cle management of an application or piece of software. The methodology within
the SDLC process can vary across industries and organizations, but standards
such as ISO/IEC 12207 represent processes that establish a lifecycle for soft-
ware, and provide a mode for the development, acquisition and configuration of
software systems. Benefits of the SDLC Process the intent of an SDLC process
is to help produce a product that is cost-efficient, effective and of high quality.
Once an application is created, the SDLC maps the proper deployment and
decommissioning of the software once it becomes a legacy. The SDLC method-
ology usually contains the following stages: Analysis (requirements and design),
construction, testing, release and maintenance (response). Vera code makes it
possible to integrate automated security testing into the SDLC process through
the use of its cloud-based platform.

Figure 3.1: SDLC

(pinterest.com)

The Agile Methodology Agile is an iterative, team-based approach to develop-

ment. This approach emphasizes the rapid delivery of an application in complete
functional components. Rather than creating tasks and schedules, all time is
time-boxed into phases called sprints. Each sprint has a defined duration (usually
in weeks) with a running list of deliverables, planned at the start of the sprint.
Deliverables are prioritized by business value as determined by the customer. If
all planned work for the sprint cannot be completed, work is reprioritized and
the information is used for future sprint planning.
As work is completed, it can be reviewed and evaluated by the project team
and customer, through daily builds and end-of-sprint demos. Agile relies on a

SKNCOE, Pune. 10 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

very high level of customer involvement throughout the project, but especially
during these reviews. Some advantages of the agile approach are easy to see:

• The customer has frequent and early opportunities to see the work being delivered,
and to make decisions and changes throughout the development project.

• The customer gains a strong sense of ownership by working extensively and directly
with the project team throughout the project.

• If time to market for a specific application is a greater concern than releasing a full
feature set at initial launch, Agile can more quickly produce a basic version of
working software which can be built upon in successive iterations.

• Development is often more user-focused, likely a result of more and frequent di-
rection from the customer. For more Agile Development benefits please see 8
Benefits of Agile Software Development

And, of course, there are some disadvantages:

• The very high degree of customer involvement, while great for the project, may
present problems for some customers who simply may not have the time or
interest for this type of participation.

• Agile works best when members of the development team are completely dedicated
to the project.

Figure 3.2: Agile Methodology

(pinterst.com)

SKNCOE, Pune. 11 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

Chapter 4
SYSTEM DESIGN

System architecture is broadly divided into 3 parts, the input, the processing unit
and the output. In input blood sample is taken from the patient. The processing unit
is further divided into image capturing system. The image is captured with the help
of camera. The image processing algorithm will run on GPU to achieve parallelism
and faster processing. The pattern matching algorithm used is SVM based histogram
classification. The output from the system is the blood group of the patient.

4.1 System Architecture

Figure 4.1: System Architecture

SKNCOE, Pune. 12 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

4.2 DFD
A data flow diagram (DFD) is a graphical representation of the “flow” of data through
an information system, modelling its process aspects. A DFD is often used as a pre-
liminary step to create an overview of the system without going into great detail,
which can later be elaborated.

4.2.1 DFD 0
A level 0 data flow diagram (DFD), also known as a context diagram, shows a data
system as a whole and emphasizes the way it interacts with external entities. This
DFD level 0 example shows how such a system might function within a typical retail
business.

Figure 4.2: DFD 0

SKNCOE, Pune. 13 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

4.2.2 DFD 1
A level 1 data flow diagram (DFD) is more detailed than a level 0 DFD but not as
detailed as a level 2 DFD. It breaks down the main processes into sub processes that
can then be analyzed and improved on a more intimate level.

Figure 4.3: DFD 1

SKNCOE, Pune. 14 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

4.3 Entity Relationship Diagram

An entity relationship diagram (ERD) shows the relationships of entity sets stored
in a database. An entity in this context is a component of data. In other words,
ER diagrams illustrate the logical structure of databases. At first glance an entity
relationship diagram looks very much like a flowchart. It is the specialized symbols,
and the meanings of those symbols, that make it unique.

Figure 4.4: ERD

SKNCOE, Pune. 15 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

4.4 UML Diagrams

The Unified Modeling Language (UML) is a general-purpose, developmental, model-
ing language in the field of software engineering, that is intended to provide a standard
way to visualize the design of a system.UML 2 has many types of diagrams, which
are divided into two categories.Some types represent structural information, and the
rest represent general types of behavior, including a few that represent different as-
pects of interactions.Unified Modeling Language, is a standardized modeling language
consisting of an integrated set of diagrams, developed to help system and software
developers for specifying, visualizing, constructing, and documenting the artifacts of
software systems, as well as for business modeling and other non-software systems.
The UML represents a collection of best engineering practices that have proven suc-
cessful in the modeling of large and complex systems. The UML is a very important
part of developing object oriented software and the software development process.
The UML uses mostly graphical notations to express the design of software projects.
Using the UML helps project teams communicate, explore potential designs, and
validate the architectural design of the software.

4.4.1 Class Diagram

The class diagram is a central modeling technique that runs through nearly all object-
oriented methods. This diagram describes the types of objects in the system and
various kinds of static relationships which exist between them.

Relationships There are three principal kinds of relationships which are important:

Association - represent relationships between instances of types (a person works for a

company, a company has a number of offices.

Inheritance - the most obvious addition to ER diagrams for use in OO. It has an
immediate correspondence to inheritance in OO design.

Aggregation - Aggregation, a form of object composition in object-oriented design.

SKNCOE, Pune. 16 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

Figure 4.5: Class Diagram

SKNCOE, Pune. 17 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

4.4.2 Activity Diagram

Activity diagram is another important diagram in UML to describe the dynamic
aspects of the system. Activity diagram is basically a flowchart to represent the flow
from one activity to another activity. The activity can be described as an operation
of the system. The control flow is drawn from one operation to another.

Figure 4.6: Activity Diagram

SKNCOE, Pune. 18 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

4.4.3 Sequence Diagram

Sequence diagrams are sometimes called event diagrams or event scenarios.A sequence
diagram shows, as parallel vertical lines (lifelines), different processes or objects that
live simultaneously, and, as horizontal arrows,the messages exchanged between them,
in the order in which they occur.

Figure 4.7: Sequence Diagram

SKNCOE, Pune. 19 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

4.4.4 Use case Diagram

Use case diagrams are usually referred to as behavior diagrams used to describe a set
of actions (use cases) that some system or systems (subject) should or can perform
in collaboration with one or more external users of the system (actors).

Figure 4.8: Use Case Diagram

SKNCOE, Pune. 20 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

Chapter 5
PROJECT PLAN

5.1 Project Estimates

Estimating is a critical part of project planning, involving a quantitative estimate
of project costs, resources or duration. One conundrum in estimating, especially for
public-sector projects, is that bidders sometimes make overly optimistic estimates in
order to win the business.

5.1.1 Reconciled Estimates

Phase I: Discovery (from one to two weeks)
The goal is to gather requirements and evaluate whether Machine Learning fits your
business goals. You need to confront your vision with the engineers who will inform
you what problems can be solved with the use of the current state-of-the-art and what
metrics can be used to measure it.
First, metrics and business goals are often different. Users can rate movies by
giving them from 1 to 10 stars. Let’s say an algorithm can be trained to predict these
outcomes with 90 percent accuracy. Sounds great but, from the business perspective,
it may be more helpful to know if a viewer is going to watch the whole movie or switch
to something else. It does not have to correlate with their star ratings.
Second, the development team needs to recognize what kind of data you have. Are
you gathering it correctly? Or maybe the data needs to be fetched from an outside
service?
Third, can we supervise the algorithm? Can we give it the correct answer each
time it makes a prediction? It’s a critical question, since unsupervised algorithms
which have to make the decision on their own are much more difficult to train. It’s
like making the prediction from the previous paragraph without having the feedback
from the review site.
Four, during this stage we estimate the Proof of Concept (PoC), i.e. exactly what
we want to achieve, something like: ”we want the model to predict whether a user
will watch the whole movie and have our prediction be accurate 70 percent of the
time”.
As you can imagine, depending on the PoC, the project may be trivial for the ML
engineers and bring a substantial business value, or the other way around. That is
why smart goals are so important.
Let me give you another example. If we build an algorithm for detecting cats in
images, we might demand it to reach 99 percent accuracy. On the other hand, in an
experiment published in the journal Annals of Oncology, a Machine Learning program
was able to tell the difference between images showing cancerous skin changes and
benign ones with 95 percent accuracy, while dermatologists were only 86.6 percent
accurate - this was the benchmark to beat to bring revolutionary positive change to
predictive medicine.

SKNCOE, Pune. 21 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

Phase II: Exploration (4-6 weeks)

At this stage, the objective is to build a Proof-of-Concept model that will be installed
as an API. Once we have trained a baseline model that is performing the task, we
can estimate the goal performance of our production-ready solution.
Once again, smart matching of business goals with ML metrics prove to be bene-
ficial. When testing a recommendation system for an e-commerce site, if there were
no advanced recommendations before, a trained baseline model can be implemented
at a very early stage, practically when it’s performing the task.
On the other hand, this may become an extremely difficult problem if we are
working on improving an already effective recommendation system.
At the end of the exploration phase, the team should be able to estimate what
performance can be achieved with any of the metrics planned during the discovery
phase.
Phase III: Development (+3 months)
It’s time for the bespoke software development team to work iteratively until they
reach a production-ready solution. As there are fewer uncertainties with each step of
the project, at this stage estimation is getting more precise.
When training an algorithm, we can react to each output of our experiments as
we watch the computer program write another computer program.
An algorithm learns very fast, we make a test on a set of data, we apply the
metric, and see if the result has reached our goal or, if not, how far away we are. If
we wanted our recommendation module to predict a viewer watching the whole movie
with 70 percent accuracy, and our model is still at 55 percent, we need to readjust
the algorithm and run it once again until we reach the goal.
If the result is not improving, sometimes the engineers have to apply a different
model or change the method, or adjust the data. We do it until we reach the goal
measured with the metric.
In this phase, the team is working in sprints, deciding after each iteration what to
do next. The outcomes of each sprint can be predicted efficiently, however planning
more than one sprint ahead is a mistake, especially in Machine Learning, where you
are often sailing on uncharted water.
Phase IV: Improvement (indefinite)
When we have already deployed a solution to the production environment, business
decision makers are often tempted to end the project in order to cut costs. In Machine
Learning technology this is often a mistake. Usually, the data, such as user preferences
and trends, changes over time. That is why an AI model needs to be constantly
monitored and reviewed to protect it from erosion and degradation.
Machine Learning projects need time to achieve satisfying results. Even if you are
lucky and your algorithms beat the benchmarks immediately, chances are it’s just one
strike, and your program will get completely lost using a different dataset.
That is why the improvement phase is perpetual. It can be done efficiently and
does not need as many resources as the previous two phases, nevertheless, it has to
be done. Continuous monitoring will not only protect the model from degradation,
but improve it over time.
Machine Learning brings uncertainty to the project. That is why pays off to get the
best and most experienced engineering team involved. Defining business goals and
metrics, sketching architecture, and planning technical requirements at the earliest
stage will determine the failure or success of your venture.

SKNCOE, Pune. 22 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

5.1.2 Project Resources

• Cost Management: Accurate estimation of cost is critical for the budgeting, plan-
ning and tracking of a project. Depending on the type of project, different
mathematical models can be used for cost estimation. AI can use any of these
models and derive insights from past data to arrive at an accurate forecast of
project cost. It can also track the project cost in real time by means of MIS
dashboards.

• Time Management: AI can analyze past projects and resources to produce an

optimal project schedule. If there is a change in project scope or if the resource
plan is changed, AI can immediately provide a revised schedule at as well.

• Risk Management: AI enhances risk management capabilities of a project man-

ager by understanding the risk factors and thresholds of a specific project. It
supports simulation of risk factors and employs fuzzy logic to assess risk in in-
frastructure projects. AI can predict obstacles by means of real time analysis
of data.

• Human capital Management: AI can recommend the best suited employees for
a project by matching project requirements with the skill sets of the employees
registered in the database. If there are no suitable resources available, it can
recommend the training that the employees need or in some cases, scan external
databases and provide a list of suitable candidates who can be hired for the
project.

SKNCOE, Pune. 23 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

5.2 Risk Management

Risk management is the identification, evaluation, and prioritization of risks (defined
in ISO 31000 as the effect of uncertainty on objectives) followed by coordinated and
economical application of resources to minimize, monitor, and control the probability
or impact of unfortunate events or to maximize the realization of opportunities.

• Algorithmic bias: Machine-learning algorithms identify patterns in data and cod-

ify them in predictions, rules and decisions. If those patterns reflect some ex-
isting bias, the algorithms are likely to amplify that bias and may produce
outcomes that reinforce existing patterns of discrimination.

• Overestimating the capabilities of AI: Since AI systems do not understand

the tasks they perform, and rely on their training data, they are far from infal-
lible. The reliability of their outcomes can be jeopardized if the input data is
biased, incomplete or of poor quality.

• Programmatic errors: Where errors exist, algorithms may not perform as ex-
pected and may deliver misleading results that have serious consequences.

• Risk of cyber attacks: Hackers who want to steal personal data or confidential
information about a company are increasingly likely to target AI systems.

• Legal risks and liabilities: At present, there is little legislation governing AI,
but that is set to change. Systems that analyze large volumes of consumer data
may not comply with existing and imminent data privacy regulations, especially
the EUs General Data Protection Regulation.

• Reputational risks: AI systems handle large amounts of sensitive data and make
critical decisions about individuals in a range of areas including credit, educa-
tion, employment and health care. So any system that is biased, error-prone,
hacked or used for unethical purposes poses significant reputational risks to the
organization that owns it.

SKNCOE, Pune. 24 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

5.2.1 Risk Identification

Do a root analysis:
Often, risk registers are filled with big, fluffy risks that are not risks at all. They are
outcomes that could arise from many different circumstances. These circumstances
are the risks we can plan for and mitigate.
There are a number of techniques that allow you to get at the cause of a problem
like we ran out of money or the project over-ran and so identify the underlying risk.
We dont have space in this short article to examine them, but there are plenty of
places where you can find out about them. For risk identification, I favor the simpler
approaches, so my short list consists of:
The Ishikawa method also known as the Fishbone Method. This is good for
finding multiple causes to an unwanted outcome. The Five Whys method This is
ideal for drilling down to the root causes. By the way, there is no special magic to
the number five; sometimes, you can get to the root of the problem with fewer steps;
sometimes you need more. The 5W2H method Seven questions about a potential
adverse outcome will give you the basis for systematic investigation: What? Why?
When? Where? Who? How often? How much/how many?

Create a Risk Breakdown Structure:

Serious project managers, planning a complex project will always create a work break-
down structure (WBS). This forms the basis of a way to identify risks, which gives you
maximum rigor. For each activity at the lowest level of your WBS (or each product if
that is how you do it), identify all of the risks in undertaking the activity or creating
the product. These can be numbered logically, extending your WBS numbering.
An alternative is to create a risk breakdown structure from scratch. Start with
a set of risk categories, like schedule, scope, budget, quality, or the example risk
categories in the Historic Data paragraph above. For each one, break it down to
component risks, and continue until you have a full breakdown of all of your project
risks. Again, the WBS numbering system will give each risk a unique identifier for
use in your risk register.

SKNCOE, Pune. 25 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

Table 5.1: Risk identify

SKNCOE, Pune. 26 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

5.2.2 Risk Analysis

Once you’ve identified the threats you’re facing, you need to calculate out both the
likelihood of these threats being realized, and their possible impact.
One way of doing this is to make your best estimate of the probability of the event
occurring, and then to multiply this by the amount it will cost you to set things right
if it happens. This gives you a value for the risk:
Risk Value = Probability of Event x Cost of Event
As a simple example, imagine that you’ve identified a risk that your rent may
increase substantially.
You think that there’s an 80 percent chance of this happening within the next
year, because your landlord has recently increased rents for other businesses. If this
happens, it will cost your business an extra 500,000 over the next year.

Risk Scores
Risk score is a calculated number (score) that reflects the severity of a risk due to
some factors. Typically, project risk scores are calculated by multiplying probability
and impact though other factors, such as weighting may be also be part of calculation.
For qualitative risk assessment, risk scores are normally calculated using factors based
on ranges in probability and impact. In quantitative risk assessments, risk probability
and impact inputs can be discrete values or statistical distributions.

Risk Probability ranges

Risk probability characterizes the chance that a certain event may occur during the
course of a project. For example probability could be categorized into 5 levels: Very
Low, Low, Medium, High, or Very High. The problem with these categories is that
they can be very ambiguous and have different meanings depending upon who you
asks. Some methods attempt to improve this by using categories such as Rare, Un-
likely, Possible, Probable and Certain; however, this still leaves us with the question
of defining what these terms actually mean.
To clarify this we can add additional detail to each probability category so that there
is a common understanding i.e. What does Rare or Very Low Probability mean?
Therefore, it is recommended that each category has a probability definition. An
example could be as shown below:
Label Probability range
Very Low 1 in 100
Low 1 in 10
Medium 1 in 5
High 1 in 2
Very High 1in 2
In this way, when assessing probability, all team members have a common under-
standing of the meaning of each category
Risk Impact Ranges
Like probability matrixes, assessing impacts can be just as problematic, if there is
not a common definition of what each impact level means. In addition, risk impacts
can affect more than one project objective such as cost, schedule, safety, quality or
others. These are referred to as risk categories and can be assessed independently.
For each risk category, we want to provide a common definition to aid in the as-

SKNCOE, Pune. 27 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

sessment
Label Cost Schedule Safety
Very Low less than 1 1 day Non injury accident
Low 1-5 less than 1 week Requires medical attention
Medium 6-10 2 weeks Requires hospitalization
High 11- 20 1 month greater than 1 day work lost
Very High greater than 20 greater 1 month greater Fatality

Calculating Risk Scores

In order to calculate risk score, we need assign a value to each of the probability and
impact levels (e.g. 1, 2, 3, 4, 5). Our matrix now includes these values for each label
Label Probability Cost Schedule Safety
Very Low: 1 1 in 100 less 1 1 day Non injury accident
Low: 2 1 in 10 1-5 less 1 week Requires medical attention
Medium: 3 1 in 5 6-10 2 weeks Requires hospitalization
High: 4 1 in 2 11- 20 1 month greater 1 day work lost
Very High: 5 less than 1 in 2 greater 20 greater 1 month greater Fatality
If we had risk that was assessed to have a high probability and medium impact it
would land on the matrix as shown below.

The risk score = High (4) x Medium (3)= 12

Risk scores can then be further defined into categories such as Catastrophic, Seri-
ous, Moderate, and Low based on the calculated score

Catastrophic: greater than 15

Serious: greater than 10
Medium: greater than 5
Low: less than 4

5.2.3 Overview of Risk Mitigation,Monitoring,Management

Risk Mitigation, Monitoring and Management Plan (RMMM) documents all work
performed as part of risk analysis and is used by the project manager as part of the
overall project plan.RIS is maintained using a database system, so that creation and
information entry, priority ordering, searches, and other analysis may be accomplished
easily. Risk monitoring is a project tracking activity

Three primary objectives:

assess whether predicted risks do, in fact, occur
ensure that risk aversion steps defined for the risk are being properly applied
collect information that can be used for future risk analysis.

SKNCOE, Pune. 28 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

Probability x highest impact: this is a very common qualitative risk scoring cal-
culation in which the highest impact score for all of the impact is used to calculate
the risk score. For example, if you had a risk that had been assessed:

Probability: Very High (5)

Schedule: High (4)
Cost: Medium (3)
Safety: Low (2)
Risk score = Probability (5) x Highest Impact (4) = 20

Probability * Average Impact

This takes the probability and multiples it by the average score of all risk impacts.
Using the example above, the risk score would be calculated:
Risk Score = Probability (5) x 4+3+2/= 5 x 3 = 15
So we can see that the risk scoring calculation can have a fairly substantial impact
on how the risk is assessed.

Calculation Risk Scores Based on Results of Quantitative Analysis

Calculating risk scores from quantitative risk analysis, such as schedule risk analy-
sis, integrated cost and schedule risk analysis and others is both more complex and
without any standard process. The reason for the complexity is that the inputs for
the analysis are not ranges or labels of ranges, but can be expressed in numerous ways:

discrete percentages (e.g. 25 probability that a risk will occur)

relative values: a 25 delay in a task
fixed values: a 15 day acceleration of a task
statistical distributions: cost impacts with a Beta statistical distribution with Low
25,000, Most Likely 35,000, and High of 50,000.
Impacts could be actions that restart, end, or cancel activities. In addition, risk scores
have to account for the schedule precedent network, task cruciality, and critical path.
An example would be where you r a risk with a high probability and impact that is
assigned to a task that is not critical or near critical path. Though the risk may have
a large impact on the specific task(s) and push it successors, it may have little or no
effect on the overall project finish time. If we looked at a sensitivity analysis we would
see that it has a very low correlation coefficient between the duration of the activity
with the large risk and the project finish time. Because of this, we recommend that
risk scores use Spearman Rank Correlation as part of the risk score calculation.

The process for calculating the quantitative risk score:

During simulation record the impact of risk on project parameters during each iter-
ation. An example, Risk A occurs and causes 3 day delay and 20,000 cost increase.
Calculate the Spearman Rank Order coefficient between schedule and cost impacts
for each risk and Project Cost, Finish Time, Duration etc. Normalize the correlation
coefficient. Calculate probability based on the number of times the risk occurred dur-
ing the simulation. This can be complicated as it is possible for risks to have multiple
probabilities per assignment as well as different probabilities for different activities.
Risk score for each risk category can now be calculated: calculated probability multi-

SKNCOE, Pune. 29 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

plied on normalized correlation coefficient. For risks that impact multiple categories,
risk score for each category multiplied by a weight that represents the relative im-
portance of the category. For example, if you had cost and schedule categories and
schedule is 2x as important as cost, you would get an importance coefficients of .667
for schedule and .333 for Cost. Depending upon how you are analyzing your projects,
the process you use can have a large impact on how your risks are assessed. Make sure
you are aware of how the risks will be assessed and that you have common guidelines
that explain how project probability and impact are assessed and the methodology
used to calculate the risk scores.

Table 5.2: category of RISK

SKNCOE, Pune. 30 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

Table 5.3: RMMM

5.3 Project Schedule

Before anything else, AI cannot fully replace human project managers. Project man-
agement demands a level of human relationships and flexibility that AI tools are
unable to deliver.
For example, project managers need to be able to negotiate and compromise on re-
sources and the ways theyre used. They need good communications skills, and the
emotional understanding to not only inspire their teams but resolve conflicts and
problems as they arise.
AI is not currently capable of any of these things. However, while AI is not suitable
to work as a project manager itself, there are many skills and processes in project
management that AI can assist with.

5.3.1 Project Task Set

Planning and project setup
• Define the task and scope out requirements

• Determine project feasibility

SKNCOE, Pune. 31 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

• Discuss general model tradeoffs (accuracy vs speed)

• Set up project codebase

Data collection and labeling

• Define ground truth (create labeling documentation)

• Build data ingestion pipeline

• Validate quality of data

• Revisit Step 1 and ensure data is sufficient for the task

Model exploration

• Establish baselines for model performance

• Start with a simple model using initial data pipeline

• Overfit simple model to training data

• Stay nimble and try many parallel (isolated) ideas

• Find SoTA model for your problem domain (if available)

• Revisit Step 1 and ensure feasibility

• Revisit Step 2 and ensure data quality is sufficient

Model refinement

• Perform model-specific optimizations

• Iteratively debug model as complexity is added

• Perform error analysis to uncover common failure modes

• Revisit Step 2 for targeted data collection

Testing and evaluation

• Evaluate model on test distribution

• May necessitate additional training

• Understand differences between train and test set

• Revisit model evaluation metric

• Ensure that this metric drives desirable downstream

Write tests for

SKNCOE, Pune. 32 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

• Input data pipeline

• Model inference functionality

• Model inference performance on validation data

• Explicit scenarios expected in production

Model deployment

• Expose model via a REST API

• Deploy new model to small subset of users

• Maintain the ability to roll back model to previous versions

• Monitor live data and model prediction distributions

Ongoing model maintenance

• Understand that changes can affect the system

• Periodically retrain model to prevent model staleness

• If there is a transfer in model ownership

SKNCOE, Pune. 33 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

5.3.2 Task Network

Task set - collection of software engineering work tasks, milestones, and deliverables
that must be accomplished to complete a particular project.
Task sets are designed to accommodate different types of projects and different degrees
of rigor.
determine type of project
assess the degree of rigor required
identify adaptation criteria
To select the appropriate task set for a project, the following steps should be
conducted:
Review each of the adaptation criteria and assign the appropriate grades (1 to 5)
based on the characteristics of the project.
Enter grade into table.
Review the weighting factors assigned to each of the criteria.
Value of a weighting factor ranges from 0.8 to 1.2 and provides an indication of
the relative importance of a particular adaptation criterion to the types of software
developed within the local environment.
Multiply the grade entered in table by the weighting factor and by the entry point
multiplier for the type of project to be undertaken.
Entry point multiplier takes on a value of 0 or 1 and indicates the relevance of the
adaptation criterion to the project type.
Result of the product
grade x weighting factor x entry point multiplier
Placed in the Product column of table for each adaptation criteria individually.
Compute the average of all entries in the Product column and place the result in the
space marked task set selector (TSS).
This value will be used to help select the task set that is most appropriate for the
project.
Defining task network
Individual tasks and subtasks have interdependencies based on their sequence.
It is likely that development activities and tasks will be performed in parallel.
Concurrent tasks must be coordinated so that they will be complete when later tasks
require their work product(s).
Task network ( activity network ) is a graphic representation of the task flow for a
project.
The task network depicts major software engineering tasks.
Parallel tasks occur asynchronously
Planner must determine intertask dependencies to ensure continuous progress toward
completion.
Project manager should be aware of those tasks that must be completed on schedule
if the project as a whole is to be completed on schedule.

SKNCOE, Pune. 34 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

Figure 5.1: Task network

5.3.3 Timeline Chart

Software project schedule - planner begins with a set of tasks
Effort, duration, and start date are input for each task.
Tasks may be assigned to specific individuals.
Depicts a part of a software project schedule that emphasizes the task for a new
word-processing (WP) software product.
All project tasks are listed in the left-hand column.
Horizontal bars indicate the duration of each task.
When multiple bars occur at the same time on the calendar, task concurrency is
implied. The diamonds indicate milestones.

SKNCOE, Pune. 35 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

SKNCOE, Pune. 36 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

Table 5.4: TimeLine Chart

5.4 Team Organization

Development teams are organized to
promote communication among the team members and between th team and inter-
ested external parties
match required skills against needs of the project
enhance overall productivity of the team

5.4.1 Team Structure

Team structure addresses the issue of organization of the individual project teams.
There are some possible ways in which the individual project teams can be organized.
There are mainly three formal team structures: chief programmer, democratic, and
the mixed team organizations although several other variations to these structures
are possible. Problems of different complexities and sizes often require different team
structures for chief solution.
Chief Programmer Team
In this team organization, a senior engineer provides the technical leadership and is
designated as the chief programmer. The chief programmer partitions the task into
small activities and assigns them to the team members. He also verifies and integrates
the products developed by different team members.The chief programmer provides an
authority, and this structure is arguably more efficient than the democratic team for
well-understood problems. However, the chief programmer team leads to lower team

SKNCOE, Pune. 37 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

morale, since team-members work under the constant supervision of the chief pro-
grammer. This also inhibits their original thinking. The chief programmer team is
subject to single point failure since too much responsibility and authority is assigned
to the chief programmer.
Democratic Team
The democratic team structure, as the name implies, does not enforce any formal
team hierarchy. Typically, a manager provides the administrative leadership. At dif-
ferent times, different members of the group provide technical leadership.
The democratic organization leads to higher morale and job satisfaction. Conse-
quently, it suffers from less man-power turnover. Also, democratic team structure is
appropriate for less understood problems, since a group of engineers can invent bet-
ter solutions than a single individual as in a chief programmer team. A democratic
team structure is suitable for projects requiring less than five or six engineers and for
research-oriented projects. For large sized projects, a pure democratic organization
tends to become chaotic. The democratic team organization encourages egoless pro-
gramming as programmers can share and review one anothers work.
Mixed Control Team Organization
The mixed team organization, as the name implies, draws upon the ideas from both
the democratic organization and the chief-programmer organization. The mixed con-
trol team organization is shown pictorially in fig. 12.4. This team organization incor-
porates both hierarchical reporting and democratic set up. In fig. 12.4, the democratic
connections are shown as dashed lines and the reporting structure is shown using solid
arrows. The mixed control team organization is suitable for large team sizes. The
democratic arrangement at the
senior engineers level is used to decompose the problem into small parts. Each demo-
cratic setup at the programmer level attempts solution to a single part. Thus, this
team organization is eminently suited to handle large and complex programs. This
team structure is extremely popular and is being used in many software development
companies.

SKNCOE, Pune. 38 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

5.4.2 Management reporting and Communication

Completing a complex project successfully requires good communication among team
members. If those team members work in the same building, they can arrange regu-
lar meetings, simply stop by each others office space to get a quick answer, or even
discuss a project informally at other office functions. Many projects are performed by
teams that interact primarily through electronic communication and are, therefore,
called virtual teams. To avoid miscommunication that can harm trust and to include
team members in a project culture, the project team needs a plan for communicating
reliably and in a timely manner. This planning begins with understanding two major
categories of communication.
Live meeting: Gathering of team members at the same location
Conference call: A telephone call in which several people participate Audio confer-
ence: Like a conference call, but conducted online using software like Skype
Computer-assisted conference: Audio conference with a connection between comput-
ers that can display a document or spreadsheet that can be edited by both parties
Video conference: Similar to an audio conference but with live video of the partici-
pants. Some laptop computers have built-in cameras to facilitate video conferencing
IM (instant messaging): Exchange of text or voice messages using pop-up windows
on the participants computer screens
Texting: Exchange of text messages between mobile phones, pagers, or personal digi-
tal assistants (PDAs)devices that hold a calendar, a contact list, a task list, and other
support programs

Figure 5.2: Template

SKNCOE, Pune. 39 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

Chapter 6
PROJECT IMPLEMENTATION

The proposed system aims to develop an embedded system which uses Image process-
ing algorithm to perform blood tests based on ABO and Rh blood typing systems.
The input to the system is the blood sample whose images are captured and forwarded
to the image processing algorithm. It uses Local Binary Pattern (LBP) for classifica-
tion of image and Chi-Square based Histogram Evaluation. We are doing histogram
evaluation to achieve more precision and accuracy while identifying whether the im-
age is agglutinated or non agglutinated. All data inside a computer is transmitted
as a series of electrical signals that are either on or off. Therefore, in order for a
computer to be able to process any kind of data, including text, images and sound,
they must be converted into binary form. If the data is not converted into binary a
series of 1s and 0s the computer will simply not understand it or be able to process
it. With the help of camera module we are going to capture 4, 16-bit images. This
16-bit images are converted into 8-bit images and finally they are further converted
into 2-bit images based on the threshold value and the output is displayed on the
screen which is in binary format. If the image captures by camera is agglutinated
the result showed on output screen will indicate 1 value for that particular images.
Similarly, if the image is non-agglutinated the result displayed on the screen will show
0 value. The image captured by camera is in red color when the image is processed
with the help of LBP algorithm it is converted into gray-scale image,this grayscale
images will be stored.The user details like, name of a person, his age, and the blood
group will also be stored for future reference.

6.1 Overview of Project Modules

Input Module: In this module, system actually takes the sample blood images as
input. It will take three Input agglutinated images of A, B and D antigens respectively.
The Systems provides 2 ways : one is capturing image using camera module and
another is by selecting it from file system.
Image Processing Modules: LBP algorithms: Local binary patterns (LBP) is a type
of visual descriptor used for classification in computer vision. It has since been found
to be a powerful feature for texture classification;it has further been determined that
when LBP is combined with the Histogram of oriented gradients (HOG) descriptor,
it improves the detection performance considerably on some datasets. Chi-square
histogram evaluation: We are doing histogram evaluation to achieve more precision
and accuracy while identifying whether the image is agglutinated or non agglutinated.
Database: System uses mySQL database to store the information about the patient
and the location (file path) of image in file system.
User: The system provides following services to user, Firstly the user will input image
after that system processes that input image then stores required data and finally gives
output. It also offers access to the all the past data stored.

SKNCOE, Pune. 40 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

6.2 Tools and Technologies Used

Visual Studio
OpenCV library
C++
mySQL

6.3 Algorithms
6.3.1 LBP Algorithm
Local Binary Pattern-Local binary patterns (LBP) is a type of visual descriptor used
for classification in computer vision. LBP is the particular case of the Texture Spec-
trum model proposed in 1990. LBP was first described in 1994. It has since been
found to be a powerful feature for texture classification; it has further been deter-
mined that when LBP is combined with the Histogram of oriented gradients (HOG)
descriptor, it improves the detection performance considerably on some datasets.

Figure 6.1: LBP Algorithm

The LBP feature vector, in its simplest form, is created in the following manner:

• Divide the examined window into cells (e.g. 16x16 pixels for each cell).

• For each pixel in a cell, compare the pixel to each of its 8 neighbors (on its left-top,
left-middle, left-bottom, right-top, etc.). Follow the pixels along a circle, i.e.
clockwise or counter-clockwise.

• Where the center pixel’s value is greater than the neighbor’s value, write “0”.
Otherwise, write “1”. This gives an 8-digit binary number (which is usually
converted to decimal for convenience).

SKNCOE, Pune. 41 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

• Compute the histogram, over the cell, of the frequency of each “number” occurring
(i.e., each combination of which pixels are smaller and which are greater than
the center). This histogram can be seen as a 256-dimensional feature vector.
Optionally normalize the histogram.

• Concatenate (normalized) histograms of all cells. This gives a feature vector for
the entire window.

The feature vector can now be processed using the Support Vector Machine or some
other machine learning algorithm to classify images. Such classifiers can be used for
face recognition or texture analysis.

1. Chi-Square Histogram Comparison

• To compare two histograms (H1 and h2), first we have to choose a metric
d(h1,h2 ) to express how well both histograms match.
• OpenCV implements the function compareHist to perform a comparison.
It also offers 4 different metrics to compute the matching:
(a) Correlation ( CV COMP CORREL )

(b) Chi-Square ( CV COMP CHISQR )

(c) Intersection ( method=CV COMP INTERSECT )

SKNCOE, Pune. 42 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

Chapter 7
SOFTWARE TESTING

7.1 Types of Testing

Beta Testing :
After the application was used in various tests, the program was given to users for
operating without any presence of developer/tester. It was observed after getting
the results that the system was working as expected, it was efficient and easily pro-
grammable by the individual/pathologists. It made the pathologists easy to manage
the blood group detection process.
Integration Testing:
Individual software modules are combined and tested as a group. It occurs after
unit testing and before validation testing. Integration testing takes input as modules,
groups them in larger aggregates., applies tests defines in an integration test plan to
those aggregates, and delivers as its output the integrated system ready for testing.
Top-down integration testing approach to testing where the top integrated module
are tested first and the branch of the module is tested step by step until the end of the
related module. The purpose of integration testing is to verify functional, performance
and reliability requirements placed on major design items.
Load Testing:
Load testing is the process of putting a demand on a system or device and measur-
ing its response. Load testing is performed to determine a systems behavior under
both normal and anticipated peak load conditions. It helps to identify the maximum
operating capacity of an application as well as any bottlenecks and determine which
element is causing degradation. When the load placed on the system is raised beyond
normal usage patterns, in order to test the system’s response at unusually high or
peak loads. Load testing is usually a type of non-functional testing although it can
be used as a functional test to validate suitability for use.

7.2 Test Cases And Test Result

following are the test cases and test result

SKNCOE, Pune. 43 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

SKNCOE, Pune. 44 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

Table 7.1: Test cases

SKNCOE, Pune. 45 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

Chapter 8
Result

8.1 Screenshot

Figure 8.1: Main Form

Figure 8.2: OPEN FORM

SKNCOE, Pune. 46 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

Figure 8.3: Camera Form

Figure 8.4: Retrieve Form

SKNCOE, Pune. 47 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

Figure 8.5: Output Form

SKNCOE, Pune. 48 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

Chapter 9
CONCLUSION AND FUTURE WORK

Thus, we have automated the blood group detection process by developing an embed-
ded system which will capture the images of the blood sample and add antigens to
it. Then the chemical reaction between the blood sample will take place and either
agglutinated or non-agglutinated images are formed.The images are then passed to
the computer where the actual image processing algorithm will process these images
and the output is displayed to the user.

SKNCOE, Pune. 49 Dept. of Computer Engg.

Blood Group Detection Using Image Processing

Chapter 10
REFERENCES

[1] G. Ravindran Assistant, T. Joby Titus, M. Pravin, “Determination and Clas-

sification of Blood Types using Image Processing Techniques”, International
Research Journal of Engineering and Technology (IRJET) , May-2018

[2] Yue fang dong, “ABO Blood Group Detection Based on Image Processing Tech-
nology”, IEEE 2nd International Conference on Image, Vision and Comput-
ing,2017

[3] Ms.K.Cibimuthu, Dr.T.Gunasekar, Mrs.P.Kokila, “A Novel approach for Blood

Tests based on Image Processing Techniques”, IJSRD - International Journal
for Scientific Research Development, 2017

[4] Neha Srivathsa, “Automated ABO Rh-D Blood Type Detection using Smart-
phone Imaging for Point-of-Care Medical Diagnostics”, IEEE Engineering in
Medicine and Biology Society Annual Conference ,Aug 2016

[5] Mehedi Talukder ,Md Rabiul Islam etc, “Improvement of Accuracy of Human
Blood Groups Determination using Image processing Techniques”, International
Journal of Advanced Research in Computer and Communication Engineering ,
October 2015

[6] Tejaswini H V, 2M S Mallikarjuna Swamy, “Determination and Classification of

Blood Types using Image Processing Techniques”, ITSI Transactions on Elec-
trical and Electronics Engineering (ITSI-TEEE),2014

[7] Nazia Fathima S.M, “Classification of blood type by microscopic color images
,International Journal of Machine Learning and Computing”. International
Journal of Machine Learning and Computing, Vol. 3, No. 4, August 2013

[8] Ana Ferraz , “Automatic System For Determination of Blood Types Using Image
Processing Techniques”, 2013 IEEE 3rd Portuguese Meeting in Bioengineering
(ENBENG),Feb 2013

[9] https://en.wikipedia.org/wiki/Localbinarypatterns

[10] http://docs.opencv.org/2.4/doc/tutorials/imgproc/histograms /histogramcom-

parison/histogramcomparison.html

[11] https://www.researchgate.net/post/whygraylevelimagearethemostpreferred im-

ageformat

SKNCOE, Pune. 50 Dept. of Computer Engg.