WHITEBOARD CAPTURE AND PROCESSING FOR E-LEARNING

A
Report

Submitted by

As the partial fulfillment of the requirement for the degree of Bachelor in Information
Technology

Guided by
 CERTIFICATE
This is to certify that the following students have submitted synopsis on the project titled

WHITEBOARD CAPTURE AND PROCESSING FOR E-LEARNING

At
College of Engineering,
as a partial fulfillment of the requirement for the degree of Information Technology

Internal Guide

Internal Examiner External Examiner

Vice Principal (Acad) and HOD, IT Dept. Principal

 ACKNOWLEDGEMENTS

We thank the Management of College of Engineering and our Principal, for providing us with
all the facilities needed to complete the project.

We would like to convey our heartfelt gratitude to our Head of Department, Prof Joshi and our
Internal Guide Mrs. shah for inspiring us to take up this project. Their valuable guidance and
timely support, without which we would have never been able to complete the project, cannot be
forgotten.

Finally, we would like to express our gratitude for the faculty members of Information
Technology of College of Engineering, and thank them for their co-operation and timely
assistance and also our loved ones for their moral support.
 INDEX

1. Abstract
2. Review of literature
3. Existing systems
4. Problem Definition with Scope of the Project
5. Proposed System
6. Feasibility study
7. Estimation and planning
7.1 Estimation
7.2 Time chart
8. Development tools
8.1 Software requirements
9. Requirement analysis
9.1 User classes
9.2 Software interface
9.3 Other requirements
10. Software design specification
11. References
LIST OF FIGURES

4.1 Block diagram

5.1 Block diagram
5.2 Timeline graph
5.3 Flow graph
5.4 Flow graph
10.1 Dataflow level 0
10.2 Dataflow level 1
10.3 Dataflow level 2
10.4 Class Diagram

LIST OF TABLES

7.1 Work breakdown structure

7.2 Timeline Chart
10.1 Requirement cross-ref Table
 1. ABSTRACT

Our aim is to analyze the sequence of captured video images in real time, classifies the pixels
into whiteboard background, pen strokes and foreground objects (e.g., people in front of the
whiteboard), extracts newly written pen strokes, and corrects the color to make the whiteboard
completely white. This allows us to transmit whiteboard contents using very low bandwidth to
remote meeting participants. Combined with other teleconferencing tools such as voice
conference and application sharing, our system becomes a powerful tool to share ideas during
online meetings.

In this project, we present a new system that combines the affordances of existing whiteboards
with complementary digital tools that facilitate the retrieval, repurpose, reflection, and use of
whiteboard content long after its initial creation, whether or not it is still on the board.

Our system captures whiteboard content without explicit intervention from the user and stores
content along with descriptive metadata. It provides multiple interfaces for users to retrieve
previously-captured content by time, by position on the board, and by various other metadata, as
well the ability to share content with peers. It improves captured content by correcting
perspective distortion, by improving image contrast, and by compensating for changes due to
light levels and for people moving through the field of view of the camera.
 2. REVIEW OF LITERATURE

(a)Books

Introduction to MATLAB 7 for Engineers -- This is a simple, concise book designed to be

useful for beginners and to be kept as a reference. MATLAB is presently a globally available
standard computational tool for engineers and scientists.

Graphics and GUIs with MATLAB -- Provides a solid understanding of when to use GUIs
and what works well graphically in various situations. Incorporates thorough updates that
reflect advances in the latest version of MATLAB.

Digital Image Processing Using MATLAB -- Digital Image Processing Using MATLAB is
the first book that provides a balanced treatment of image processing fundamentals and the
software principles used in their practical implementation. The book integrates material from
the leading text, Digital Image Processing by Gonzalez and Woods, and the Image
Processing Toolbox of the Math Works. Inc., a recognized leader in scientific computing.

Mastering MATLAB 7 -- This book covers all essential aspects of MATLAB

(b)Publications

IEEE Papers

 Abstract: This paper describes our recently developed system which captures pen strokes
on whiteboards in real time using an off-the-shelf video camera. Unlike many existing
tools, our system does not instrument the pens or the whiteboard. It analyzes the sequence
of captured video images in real time, classifies the pixels into whiteboard background,
pen strokes and foreground objects (e.g., people in front of the whiteboard), and extracts
newly written pen strokes. This allows us to transmit whiteboard contents using very low
bandwidth to remote meeting participants. Combined with other teleconferencing tools
such as voice conference and application sharing, our system becomes a powerful tool to
share ideas during online meetings [1].

 Abstract: A adaptive filter interpolation method and system for the demos icing of color
images. In general, input pixels are input in a Bayer-mosaiced pattern (only one color per
pixel), and output pixels are in full RGB mode (three color values per pixel). For each
pixel location, in raster scan order, the processing steps can be summarized as follows.
Following a regular raster scanning order (from left to right and top to bottom), for each
pixel location horizontal and vertical gradients are first computed (whose computation
depends on the available color for that pixel), and from those the appropriate
interpolation filters are chosen from a small set of predetermined filters. Then, the chosen
filters are applied to interpolate the missing data [2].
 3. EXISTING SYSTEM

3.1 Present Architecture /Block Diagram

There are a number of existing applications for screen capture. Camtasia make the most well
known desktop solution; Camtasia Studio. This provides many features including mouse pointer
highlighting, selection of recording area and video editing. There are also some free applications
such as Cam Studio for Windows, which is available as open source software.

This uses client-server architecture to offload the processing from the capture client onto a
central server. However this still requires the client-side PC to have the capture application
installed.Web based screen capture is a much more recent development. However, due to the
rapid development environment of the web, there are already a few applications available. Many
of these provide similar functionality; however, all current solutions are limited in a way that
makes them completely unusable for lecture capture.

Screencast-o-Matic (http://www.screencast-o-matic.com) is possibly the original. It is an entirely

Java based application which allows the user to select an area of the screen to record, and
captures microphone input. It provides an export function to convert the video to Quicktime
(MOV), Windows Media Video (WMV) or Flash Video (FLV) formats. One of its limitations is
that it has a maximum recording duration is 15 minutes. However, Screencast-o-Matic licenses
their capture code to others, so there are a few similar applications which utilize their code.
Screen toaster (http://www.screentoaster.com) uses a combination of Flash and Java to deliver
their application. Due to the use of Flash, their application can offer webcam capture in addition
to desktop and audio capture. It also provides the ability to playback screen capture at a speed
faster or slower than realtime. Screen toaster has, instead of a time limitation, a file size limit of
20 MB on the media which can be captured. As all video is stored on the client machine, it must
therefore be uploaded after the recording has finished.
Our application avoids this situation by sending the data during the capture process, so there is
not a backlog of image data to send after the capture.

3.2 Existing Solution Modular Description

Most solutions to this problem involve the use of complex, and usually expensive equipment.
The use of electronic capture systems requires the use of electronic presentation systems, in the
vast majority of automatic transcription methods. The use of a PC and a data projector is a
simple and fairly inexpensive approach to electronic presentation, with the use of presentation
file formats, some of which allow dynamic content like hand drawn examples to be included. At
the higher end of the scale, the use of electronic whiteboards, giant touch screens in essence, can
be used to capture a more natural presentation approach. Increasingly complex equipment though
can place a heavy financial burden on organizations that make heavy use of presentations, and
also disrupts the presentation process, as it must evolve to adopt the transcription systems.

As a way of counteracting these issues, this system has been proposed. The whiteboard capture
system is tasked with capturing a set of key frames and audio indexes, derived from a set of
continuous still images of a whiteboard, and a single source audio recording from a meeting
room. From this unobtrusive and inexpensive configuration can be derived a browse-able file
that represents that meeting, and is claimed to be an efficient method of reviewing the knowledge
worker's meeting process.
3.3 Pitfalls in Existing System

To the best of our knowledge, all existing systems that capture whiteboard content require
instrumentation either in the pens or on the whiteboard. Our system allows the user to write
freely on any existing whiteboard surface using any pen.To achieve this, our system uses an off
the-shelf high-resolution video camera which captures images of the whiteboard. From the input
video sequence, our algorithm separates people in the foreground from the whiteboard
background and extracts the pen strokes as they are deposited to the whiteboard. To save
bandwidth, only newly written pen strokes are compressed and sent to the remote participants.
Furthermore, in order to facilitate interaction from remote users, we integrate a projector in the
whiteboard-camera system. The projector can project annotations from remote users as well as
contents from PowerPoint or Word documents. The whiteboard serves as the writing surface
(input) as well as the projecting surface (output). In such a system, one vital requirement is the
extraction of handwritings from video images that contain both handwritings and the projected
content. By analogy with echo cancellation in audio conferencing, we call this problem visual
echo cancellation.

\
 4. PROBLEM DEFINITION DOCUMENT

4.1 Introduction

The use of whiteboards is pervasive across a wide range of work domains. Whiteboards enable
users to quickly externalize an idea or concept, facilitate understanding among collaborators and
peers, and can serve as conversational artifacts to ground discussion. Whiteboards provide a low
overhead work surface that allows information to be freely modified by both individuals and
groups.

These affordances make whiteboards ideal tools to facilitate brainstorming and other associated
creative activities such as reflection and reinterpretation. Whiteboards also allow information
content to be persistently visible after use, facilitating activity coordination and awareness of task
progress, and supporting episodic memory.

To bring the affordances of whiteboards to digital tools, a wide range of commercial and
research tools have been developed. Despite their availability however, use of these tools is all
but nonexistent in the modern workplace while traditional whiteboards remain ubiquitous.

While there are many factors that contribute to this lack of adoption, we largely attribute it to the
poor user experience provided by current electronic whiteboard tools. For instance, the overall
fidelity of the digitizing hardware does not capture subtle nuances or expressiveness currently
well supported by physical whiteboards. Further, many of these tools focus on the ongoing task,
and offer poor support for retrieval and subsequent use of captured content. For instance, systems
such as mimio (www.mimio.com) and eBeam (www.e-beam.com) that augment traditional
whiteboard technology mitigate deficiencies of digital input, but provide little more than the
ability to export portable images of content for post-task use; the burden of organization and
management still falls on the user. We believe the content creation affordances of traditional
whiteboards to be essential to their overall success.

In this project, we present ReBoard, a new system that combines the affordances of existing
whiteboards with complementary digital tools that facilitate the retrieval, repurpose, reflection,
and use of whiteboard content long after its initial creation, whether or not it is still on the board.

ReBoard captures whiteboard content without explicit intervention from the user and stores
content along with descriptive metadata. ReBoard provides multiple interfaces for users to
retrieve previously-captured content by time, by position on the board, and by various other
metadata, as well the ability to share content with peers. ReBoard improves captured content by
correcting perspective distortion, by improving image contrast, and by compensating for changes
due to light levels and for people moving through the field of view of the camera.

ReBoard is a novel augmentation of a traditional whiteboard that combines the natural

interactions at a whiteboard to create content, with the power of a computer to manage it, thereby
mitigating some of the limitations of both electronic boards and whiteboards. In the remainder of
this document we first explore existing work practices around whiteboards to establish some
design requirements, and then describe the architecture of ReBoard and its user interfaces, and
then follow with an evaluation of the effectiveness of its capture algorithms.

4.2 Concept and Implementation

Our aim to analyze the sequence of captured video images, classifies the pixels into whiteboard
background, pen strokes and foreground objects (e.g., people in front of the whiteboard), extracts
newly written pen strokes, and corrects the color to make the whiteboard completely white.
This allows us to transmit whiteboard contents using very low bandwidth to remote meeting
participants. Combined with other teleconferencing tools such as voice conference and
application sharing, our system becomes a powerful tool to share ideas during online meetings.

4.2.1 Problem Statement

The common meeting is an integral part of everyday life for most workgroups. However, due to
travel, time, or other constraints, people are often not able to attend all the meetings they need to.
Teleconferencing and recording of meetings can address this problem.

Unfortunately though, this process is intrinsically flawed by its nature of being perceptual; in that
the person can’t see what one is writing on board because of his shadow light and so on. If
someone miss understands a concept discuss in meeting, it is forever recorded incorrectly. Even
a badly placed spelling mistake could throw off an entire meeting! Problem scenario is illustrated
in Figure 4.1.

The same scenario is applicable for the lectures taken by the professors in the classrooms. If a
reliable, unbiased record could be produced automatically, independent of any mindset then the
anyone could use their time to just understand main point of meeting. Hence we come up with
solution called as effective use of white board capture system.

4.2.2 Proposed Solution

Our project is concerned primarily with the capture of whiteboard used in meetings or lectures.
Our project has been proposed for the purpose of recording a user screen, microphone and
webcam later on which can be viewed by anyone in enhanced way. The ideal system would have
three principle aspects, recording, data capture (processing) and playback.

In this project we are targeting to effective use of white board capture system which is a part of
our Distributed Meetings project, which aims at dramatically improving knowledge workers’
meeting experience using ubiquitous computing technologies to provide a rich experience for
people who want to participate in a meeting from a distance.

A whiteboard is an effective and easy to use tool for meetings, especially in scenarios such as
brainstorming, lectures, project planning, and patent disclosures. Sometimes, meeting
participants who are on conference call from remote locations are not able to see the whiteboard
content as the local participants do. In order to enable this, the meeting sites often must be linked
with expensive video conferencing equipments.
4.2.3 Project Goals

Our system is designed with two purposes:

 To alleviate meeting participants the mundane tasks of note taking by capturing

whiteboard content automatically
 To communicate the whiteboard content to the remote meeting participants in real time
using a fraction of the bandwidth required if video conferencing equipment is used.

4.3 Conclusion

Drawing on the available research literature and on our own observations, we designed set of
augmentations for existing whiteboards to support existing practices around creation of drawings
and notes, and to leverage the power of the computer to manage that information once created.

We will be building a system that captures whiteboard images unobtrusively, without disrupting
existing work practices around content creation. The system identifies images based on
associated metadata, including the time and location on the board when the image was captured,
and whether it was created collaboratively.
 5. PROPOSED SOLUTIONS

5.1 Draft of proposal

This project is concerned primarily with the capture of whiteboard used in meetings or lectures.
Our project has been proposed for the purpose of recording a user screen, microphone and
webcam later on which can be viewed by anyone in enhanced way.

The ideal system would have three principle aspects, recording, data capture (processing) and
playback. In this project we are targeting to whiteboard capture system (WCS) which is a part of
our Distributed Meetings project, which aims at dramatically improving knowledge workers’
meeting experience using computing technologies to provide a rich experience for people who
want to participate in a meeting from a distance.

A whiteboard is an effective and easy to use tool for meetings, especially in scenarios such as b ,
lectures, project planning, and patent disclosures. Sometimes, meeting participants who are on
conference call from remote locations are not able to see the whiteboard content as the local
participants do. In order to enable this, the meeting sites often must be linked with expensive
video conferencing equipments.

Our system was designed with two purposes:

To alleviate meeting participants the mundane tasks of note taking by capturing whiteboard
content automatically.

To communicate the whiteboard content to the remote meeting participants in real time using a
fraction of the bandwidth required if video conferencing equipment is used.

5.2 Proposed Architecture

Figure 5.1 :Block Diagram of Proposed architecture

Rectify the whiteboard region of every image in the sequence.

Extract the whiteboard background color.

Cluster the cell images throughout the sequence for the same cell. If two cell images are
considered to be the same, they are clustered in the same group.

Classify each cell image as a stroke, a foreground object, or the whiteboard.

Filter the cell images both spatially and temporally to refine the classification results.

Extract the key frame images using the classification results.

Color-balance the key frame images.

5.3. Expected modules

5.3.1 Proposed Framework

We know that there is a large amount of data to be inferred, and that all this data can be
represented in human perceivable terms, i.e. audio and video.

Consider the data in terms of time; where the audiovisual input stream is a sequential, temporally
indexed collection. This timeline structure is very useful for visualizing relationships between
entities, as a user is intrinsically sequential; slides follow on from one another, sub sections are
discussed in order, etc... This is a representation that should be kept in mind, as it should be used
to reconstruct the data in the end, being the most logical way to reconstruct a lecture for a human
to then browse.
Now consider the data in terms of granularity. At the top level in video, there is one big file.
Going down we get frames, then key frames, then slides, then sub-headings, and so on (The full
hierarchy has more tiers in-between, but will be explained later on). Entities are related to each
other in terms of scope & combination; i.e. that the entities at tier n are broken down to form the
entities at tier n+1.

This view of compositionality is more of a natural way to view the entire sensor recording, as at
each layer in the granularity hierarchy, the data making up that layer is of the same type. This
makes it much easier to process; we can afford to run several passes over the same data, but each
pass need only be concerned with capturing one thing.

But why this approach? Consider if you will, trying to capture everything in terms of the timeline
model. Even if you are allowed several passes over the data, the problem is mind boggling. They
would only be addressable in sequentially ordered segments, and each segment must be checked
by all qualifiers and algorithms in the system. This would quickly spiral out of control.

We should consider an iterative approach to the resolution of this data. Starting from the sensor
capture files, we can build up a hierarchy of data, where each tier is inferred from the previous
tier. The system makes several passes over the data, each time with a new goal, and a new
algorithm to infer the relevant data. However, to restore the sequential nature of the underlying
user, that data will be stored in terms of time, as events and entities. By retaining these time
stamps, and temporal references, we can reconstruct the timeline when all the data has been
collected, allowing the final lecture format to be replayed in the sequential order of the
underlying user.

5.3.2 Break-down of Framework

The control structure of the eventual capture system should be an iterative accumulator, which
employs a distinct algorithm at each layer of iteration. The data captured by each pass of the
system would be accumulated in a single store; the data pool, such that new data is available to
subsequent passes, and that the final iteration yields data from all layers in the hierarchy.

Of course the system will not loop indefinitely; the scope of the algorithm will be defined later in
this report, but the final system should be flexible enough to allow for new data to be read, and
new algorithms for inferring useful data from the data already captured. To allow this flexibility,
we will use 'pluggable' modules. Modules should be mostly independent of each other, as the
very reason for having them is to avoid the restrictions of the core process. Each module will add
data to the pool, but should also include some method of interpreting the data it yields, for the
benefit of the eventual playback system.

5.3.3 Proposed System Structure

We must first address the setting of the video recording. Typically in video processing
applications that deal with human addressed video, like television, the setting of the video
contains useful data; however in a meeting the setting is largely irrelevant. A decision must
therefore be made, as to what is and is not relevant in the setting of the video recording.

The setting will be fixed throughout the video recording session; therefore the setting should be
able to be characterized by the first frame of the video, regardless of its content. These areas
should be enclosable with a polygonal shape, which can then be warped into a rectangle (see
figure 5.4). These sub-videos can then be processed independently of the remainder of the frame,
and each other.

5.3.4 Whiteboard Capture

The whiteboard capture algorithm analyzes the stream of images captured by the camera(s),
identifies significant events, enhances the associated images for greater legibility, and stores the
images with timing information.

To identify content to store:-

Creates a whiteboard ground truth image by breaking the camera images into blocks and giving
each block the average value of the brightest 25% of pixels in that block. The brightest part of
each block corresponds to the whiteboard pixels in the block.

The whiteboard is then made white and text, drawings and other markings are enhanced by
applying equation (1) to each color channel individually.
In equation (1), Pout, Pin, and Pground are the pixel values for the enhanced image, input camera
image, and whiteboard ground image, respectively, and 255 is full saturation of a color channel.

Consecutive enhanced images are compared to determine lecturer location. Taking a target
enhanced image and substituting the pixels from the previous image for those pixels where the
lecturer is located creates a clean whiteboard image.

The whiteboard images are then compared to determine when content changes and hence when a
new whiteboard image needs to be saved.

When a new white board image needs to be saved. The saved whiteboard images are then
sharpened and the contrast is increased. A series of images from the cameras and the captured
whiteboard content associated with them is displayed in Figure 5
 Figure 5: Sample White board result

5.4. Benefits of the proposed solution

 This allows for interaction as part of the dynamics of the lecture/discussion.

Unfortunately, as currently practiced, this usually consists of video conferencing
with the video consisting of the “talking head” of the professor.
 A better visual focus would be on the computer screen.
 Emerging electronic presentation and communications technologies can be used
to capture the dynamics of the lecture for both asynchronous and synchronous
modes of instruction.
 A design to closely simulate the classroom experience via a browser over the
Internet.
 6. FEASIBILITY STUDY OF PROPOSED SOLUTION

A feasibility study is defined as an evaluation or analysis of the potential impact of a proposed

project or program. A feasibility study is conducted to assist decision-makers in determining
whether or not to implement a particular project or program. The feasibility study will contain
extensive data related to financial and operational impact and will include advantages and
disadvantages of both the current situation and the proposed plan. The extensive research,
conducted in a non-biased manner, will provide data upon which to base a decision.

In feasibility study phase we had undergone through various steps which are describe as under:

1. Identify the origin of the information at different level.

2. Identify the expectation of user from computerized system.

3. Analyze the drawback of existing system (manual) system.

6.1 Technical feasibility

We can strongly say that it is technically feasible, since there will not be much difficulty in
getting required resources for the development and maintaining the system as well. All the
resources needed for the development of the software as well as the maintenance of the
same is available in the organization here we are utilizing the resources which are available
already.

The effective use of whiteboard content will be based on the white board capture system, but we
will make it a new system for them to have an effective use of whiteboard content. This system
could give no more hassle for the students. To integrate system the proponent decided to use new
software that will manage their lectures, it includes recorded lectures to create the effective use
of whiteboard content, we will use Matlab. This software is compatible with windows operating
systems.
6.2 Operational feasibility

Suppose for a moment that technical and economic resources are both judged adequate. The
systems analyst must still consider the operational feasibility of the requested project.
Operational feasibility is dependent on human resources available for the project and involves
Projecting whether the system will operate and be used once it is installed.

If users are virtually wed to the present system, see no problems with it, and generally are not
involved in requesting a new system, resistance to implementing the new system will be strong.
Chances for it ever becoming operational are low.

Our current educational or meeting is still using the traditional way. Our system will be helpful
because this allows for real-time interaction as part of the dynamics of the lecture/discussion.
Unfortunately, as currently practiced, this usually consists of video conferencing with the video
consisting of the “talking head” of the professor.

As final GUI will be including only two option browse and play it will be less manual work for
user.

6.3 Economical feasibility

Economic feasibility is the second part of resource determination. The basic resources to
consider are: your time and that of the systems analysis team, the cost of doing a full systems
study (including time of employees you will be working with), cost of the business employee
time, estimated cost of hardware, and estimated cost of the software and/or software
development The concerned business must be able to see the value of the investment it is
pondering before committing to an entire system study.
If short-term costs are not overshadowed by long-term gains or produce no immediate reduction
in operating costs, then the system is not economically feasible, and the project should not
proceed any further. Our system is economic because its operating system independent and we
need only Matlab to run this software

6.4 Legal feasibility

Legal feasibility involve in verifying the legal viability of the proposed system. Copyright Issue:
Since this software is using open source codes there will be minimal licensing issue and other
related issue.
 7. ESTIMATION AND PLANNING
7.1 Estimation
Constructive Cost Model (COCOMO)
COCOMO is one of the most widely used software estimation models in the world. This model
is developed in 1981 by Barry Boehm to give an estimate of the number of man-months it will
take to develop a software product.
COCOMO has three different models that reflects the complexity-
 Basic Model
 Intermediate Model
 Detailed Model
Similarly there are three classes of software projects.
Organic Mode: - In this mode relatively small, simple software projects with a small team are
handled.
Semi-detached projects: - In this class an intermediate projects in which teams with mixed
experience level are handled.
Embedded projects: - In this class, projects with tight hardware, software and operational
constraints are handled.
The basic COCOMO model estimates the software development effort using Lines of Code.
Various equations in this model are –
E= ab (KLOC) ^ bb

D= Cb (E) ^ db

P= E / D

Where E is the effort applied in person months.

D is the development time

KLOC means kilo line of code for the project

P is the total number or persons required to accomplish the project.

The coefficients ab, bb, cb, db for three models are given below.

Software ab bb cb db
projects

Organic 2.4 1.05 2.5 0.38

Semi-detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32

7.1.1 Estimates of Effort, Cost, Duration

For our project

The project is classified as an organic project, using default values a=2.4, b=1.05, c=2.5 and
d=0.38.

E= ab (KLOC) ^ bb

E=2.4 * (10.90) ^ 1.05

E=28.9 person-months or 29 person month

D= Cb (E) ^ db

D=2.5 * (29) ^ 0.38

D=8.99 months or 9 months

P= E / D

P=3.2 persons

Thus 3 persons can finish the coding part in approximately 9 months.

7.2 Timeline chart

7.1 Work Breakdown Structure

1 Problem Definition
2 Problem Evaluation
3 Study of Existing System
4 Scope
5 Feasibility
6 Requirement Analysis
7 Project Estimation
8 Project Estimation
9 Design Phase
10 Designing GUI
11 Developing algorithm various modules
12 Draw data flow diagrams of system
13 Coding
14 Unit testing
15 Integration Testing
16 System testing
 7.2 Timeline chart

(Week 1) (Week 36)

Jul 1st Apr30th
Work
task
1

10

11

12

13

14

15
 8. DEVELOPMENT TOOLS

Software Requirements

Windows XP:

RAM: 1024 MB
(At least 2048 MB recommended)

PROCESSOR: Any Intel or AMD x86 processor

DISK SPACE: 1 GB for MATLAB only, 3–4 GB for a typical installation.

Software: - Matlab 7
 9. REQUIREMENT ANALYSIS (SRS)

9.1 User Interface

User interface will be required for initializing the system.

9.2 Software Interface

MATLAB

9.3 Other Requirements

9.3.1 Performance Requirements

The following performance characteristics should be taken care of developing the system:

 Efficiency: Depend upon speed of processor.

 Response Time: Depends on processor and video resolution.
 Easy to use: This is an important feature. The user interface is simple and easy to
understand.

9.3.2 Software Quality Attributes

 Portability: The code will be written in matlab which is a proven portable language.
Thus the application can run on any operating system.

 Reliability: Reliability is achieved when the software does not crash over during
operations.
 10. SYSTEM DESIGN SPECIFICATION

10.1 Scope

10.1.1 System Objective

The Main objective of the project is to provide following things:

 Remove Lecture from Video
 Enhance the Video

10.1.2 Major software requirements

Windows XP:

RAM: 1024 MB
(At least 2048 MB recommended)

PROCESSOR: Any Intel or AMD x86 processor

DISK SPACE: 1 GB for MATLAB only, 3–4 GB for a typical installation.

Software: - Matlab 7

10.1.3 Design Constraints, Limitation

Standards
The library is programmed in the Matlab programming language.

Hardware constraints
The program runs on Pentium-level computers with at least 32 MB of memory.
Software constraints
The program must compile with the matlab compiled. Video file input to the software must have
audio extracted as audio is not processed while video processing.
Supported platforms are Windows.

10.2 Architectural Design

10.2.1 Review of Data and Control Flow

DFD Level 0

DFD level 1
DFD Level 2

10.2.2 Derived Program Structure

The underlying video data should remain intact throughout and all derived image data should
refer back to it, primarily with frame numbers. This will allow indexing of the visual sequence
and possibly allow further implementations based on this project to access the video data for
other processing techniques.

Due to the prohibitive size of raw image data, there should be as little duplication of images as
possible. To this end we will only store frame data (i.e. key-frames) in one structure, and simply
reference that structure in any associated data.

Figure 10.4 shows the program structures to be used in the system. Note that the Video_File and
Cluster structures are only partially defined. The cluster represents the grouping stage which will
be named later on, but of which we can’t make any data decisions yet. The inner workings of the
Video_File class are irrelevant to the operation of the system.

10.3 Interface Design

Hardware Interface
Our project will require basic peripheral device like keyboard, mouse
Software Interface
As the software is developed using Matlab, the user must have matlab runtime environment
installed on his computer.
Communication with other Interfaces
The system will capture a video through the camera and the output will be in the
form of a motor activation triggered by the system.

10.4 Procedural Design

List of Modules:

 Rectify

 Extract

 Cluster

 Filter

 Classify

1. Rectify

Processing narrative:

Rectify the whiteboard region of every image in the sequence.

Design language:
We are using Matlab programming language

Modules Used:

Extract, Cluster, Classify, Filter

2. Extract

Processing narrative:

Extract the whiteboard background color.

Design language:
We are using Matlab programming language

Modules Used:

Rectify, Cluster, Classify, Filter

3. Cluster

Processing narrative:

Cluster the cell images throughout the sequence for the same cell. If two cell images are
considered to be the same, they are clustered in the same group.

Design language:
We are using Matlab programming language

Modules Used:

Rectify, Extract, Classify, Filter

4. Filter

Processing narrative:

Filter the cell images both spatially and temporally to refine the classification results.

Design language:
We are using Matlab programming language
Modules Used:

Rectify, Extract, Classify, Cluster

5. Classify

Processing narrative:

Classify each cell image as a stroke, a foreground object, or the whiteboard.

Design language:
We are using Matlab programming language

Modules Used:

Rectify, Extract, Filter, Cluster

10.5 Requirements Cross-Reference

It provides a matrix showing where each feature identified in the SRS is supported by the design
components.

Process Verification Module

UI Input Video Video
Components Module Module Module

Requirements

Search for an Video X

Select option X

Check files format and option. X

Convert Video X X

Display Video X
A traceability matrix is created by associating requirements with the work products that satisfy
them. The configuration management plan is how changes will be tracked and controlled.
Traceability is a key part of managing change. Traceability ensures completeness, that all lower
level requirements come from higher-level requirements, and that all higher-level requirements
are allocated to lower level ones. Traceability also provides the basis for test planning.
 11. REFERENCES

Books:

 Engineer’s Guide to MATLAB

 Mastering MATLAB 7

 Introduction to MATLAB 7 for Engineers

 Graphics and GUIs with MATLAB.

 Digital Image Processing Using MATLAB

IEEE Papers:

[1] He, Li-wei, Liu, Z. and Zhang, Z. Why Take Notes? Use the Whiteboard Capture System
ICASSP 2003.
[2] Malvar, Henrique S., He, L. and Cutler, R. High-Quality Linear Interpolation for
Demosaicing of Bayer-Patterned Color Images. ICASSP 2004.

Web References:

www.wikipedia.com
 www.google.com