whiteboard capture and processing for e-learning

8/10/2019 Whiteboard Capture and Processing for E-learning

1/41

WHITEBOARD CAPTURE AND PROCESSING FOR E-LEARNING

Department of Information Technology, DJSCOE Page 1


ASynopsis Report

Submitted by Nisha Gor

Reema KalraJyoti Raval

As the partial fulfillment of the requirement for the degree of Bachelor in InformationTechnology

Guided by

Mrs. Neepa Shah

Department of Information Technology

D. J. Sanghvi College of Engineering,Mumbai 400 056


2/41



Shri Vile Parle Kelvani Mandals D. J. Sanghvi College of Engineering

Mumbai 400 056

CERTIFICATE

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


At D.J. Sanghvi College of Engineering, Mumbai as a partial fulfillment of the requirement for

the degree of Information Technology (Semester VII) of University of Mumbai in the year2011 2012.

Nisha Gor IF2009102Reema Kalra IF2009104Jyoti Raval IF2009107

Internal Guide(Mrs. Neepa Shah)

Internal Examiner External Examiner

Vice Principal (Acad) and HOD, IT Dept. Principal(Prof. A. R. Joshi) (Dr. Hari Vasudevan)


3/41



ACKNOWLEDGEMENTS

We thank the Management of D.J. Sanghvi 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. Abhijit Joshi

and our Internal Guide Mrs. Neepa 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 D.J. Sanghvi College of Engineering, and thank them for their co-operation and

timely assistance and also our loved ones for their moral support.

Nisha GorReema Kalra

Jyoti Raval


4/41



INDEX

1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

11.

Abstract

Review of literature

Existing systems

Problem Definition with Scope of the Project

Proposed System

Feasibility study

Estimation and planning

7.1 Estimation7.2 Time chart

Development tools

8.1 Software requirements

Requirement analysis

9.1 User classes

9.2 Software interface

9.3 Other requirements

Software design specification

References


5/41



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.4 Class Diagram

LIST OF TABLES

7.1 Work breakdown structure

7.2 Timeline Chart

10.1 Requirement cross-ref Table


6/41



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.


7/41



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 GUIsand 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


8/41



(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 computationdepends 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].


9/41



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 acentral 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


10/41



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


11/41



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.

\


12/41



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 associatedcreative 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.


13/41



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.


14/41



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 cant 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.


15/41



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 a ims 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 timeusing a fraction of the bandwidth required if video conferencing equipment is used.


16/41



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.


17/41



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 whowant 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.


18/41



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.


19/41



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 .


20/41



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 newalgorithm 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.


21/41



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.


22/41



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


23/41



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.


24/41



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.


25/41



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.


26/41



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.


27/41



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 ModelSimilarly 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= a b (KLOC) ^ b b

D= C b (E) ^ d b

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


28/41



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

The coefficients a b, b b, c b, d b for three models are given below.

Software

projects

a b b b cb d b

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= a b (KLOC) ^ b b

E=2.4 * (10.90) ^ 1.05

E=28.9 person-months or 29 person month

D= C b (E) ^ d b

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.


29/41



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 testing15 Integration Testing

16 System testing


30/41



7.2 Timeline chart

(Week 1) (Week 36)

Jul 1st Apr30th

Work

task

1

2

3

4

56

7

8

9

10

11

12

13

14

15


31/41



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


32/41



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.


33/41



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


34/41



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


35/41



DFD Level 2

10.2.2 Derived Program Structure


36/41



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 cant make any data decisions yet. T he 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 InterfaceAs the software is developed using Matlab, the user must have matlab runtime environment

installed on his computer.


37/41



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


38/41



2. Extract


Extract the whiteboard background color.

Design language:


Modules Used:

Rectify, Cluster, Classify, Filter

3. Cluster


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:


Modules Used:

Rectify, Extract, Classify, Filter

4. Filter


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

Design language:


Modules Used:


39/41



Rectify, Extract, Classify, Cluster

5. Classify


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

Design 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.

Components

UI

Module

Input Video

Module

ProcessVideo

Module

Verification Module

Requirements

Search for an Video X

Select option X

Check files format and option. X

Convert Video X X

Display Video X


40/41



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.


41/41


11. REFERENCES

Books:

Engineers 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.mathworks.com (25/09/2011) www.wikipedia.com (01/08/2011) www.google.com (15/07/2011)
http://www.mathworks.com/http://www.mathworks.com/http://www.wikipedia.com/http://www.wikipedia.com/http://www.google.com/http://www.google.com/http://www.wikipedia.com/http://www.mathworks.com/

whiteboard capture and processing for e-learning

Documents