IMAGE EDITOR

A Project Report submitted in partial fulfillment of the requirements for the award of degree of BACHELOR OF ENGINEERING IN INFORMATION TECHNOLOGY
BY

KRISHNAVENI.T(0205-3006) & KANTHI.K.L.T(0205-3007) Under the guidance of Dr. I.V. Ramana, Professor & Head, Department of IT, CBIT

DEPARTMENT OF INFORMATION TECHNOLOGY CHAITANYA BHARATHI INSTITUTE OF TECHNOLOGY HYDERABAD-75 2007-2008

DEPARTMENT OF INFORMATION TECHNOLOGY CHAITANYA BHARATHI INSTITUTE OF TECHNOLOGY

(Affiliated to Osmania University;ISO Certified 9001:2000) Chaitanya Bharathi P.O.,Gandipet,Hyderabad-500075. Website:www.cbit.ac.in, www.cbitworld.com Ph.Nos:08413-233356,54,08413-232488,87,08413-234162, Fax:08413-232099

CERTIFICATE
This is to certify that the project work entitled Image Editor is a bonafide work done and submitted by Krishnaveni.T(0205-3006) and Kanthi.K.L.T(0205-3007), in the partial fulfillment of the requirements for the award of Degree of Bachelor of Engineering in Information Technology ,Chaitanya Bharathi Institute of Technology, Affiliated to Osmania University,Hyderabad. The results embodied in this report have not been submitted to any other University or Institute for the award of any degree or diploma.

Project Guide Dr.I.V.Ramana, Professor & Head, Dept of IT., CBIT,Hyderabad.

ACKNOWLEDGEMENTS
We thank Dr. I.V.Ramana, Professor and Head, Department of Information Technology, for providing seamless support and knowledge over the past one year, and also for providing right suggestions at every phase of the development of our project. We sincerely thank, S. Pavithran for his extensive support, guidance and helping us put our ideas to work. We express a whole hearted gratitude to Dr. B.Chennakesava Rao, Principal, Chaitanya Bharathi Institute Of Technology for providing us the conducive environment for carrying through our academic schedules and projects with ease. We are grateful to Dr. I. Ramachandra Reddy, Director, CBIT for providing us with all the moral support throughout our academic schedules. We would also like to express gratitude to Prof. Suresh Pabboju for his useful inputs at every stage of our project. There is definitely a need to thank our friends and parents, without whose support project would have been deferred.

KRISHNAVENI.T(0205-3006) KANTHI.K.L.T(0205-3007)

ABSTRACT

Our project is concerned with developing an image editor in the Linux platform. An image editor is a computer program that enables a user to manipulate visual images to improve its appearance. It allows users to edit pictures interactively on the computer screen and save them in one of many graphics file formats. Basic editing operations include selecting parts of an image, cropping, scaling, sharpening and softening and changing the contrast of an image . The editor is built in C++ programming language using Qt, a toolkit which simplifies the work with graphics in C++. Qt is a cross-platform application development framework, widely used for the development of GUI programs and also used for developing nonGUI programs such as console tools and servers. Qt uses C++ with several non-standard extensions implemented by an additional pre-processor that generates standard C++ code before compilation. Qt is most notably used in KDE (K Desktop Environment) which is a free graphical desktop environment for LINUX/UNIX workstations. It provides basic desktop functions and applications for daily needs as well as tools and documentation for developers to write stand-alone applications for the system. There are many distributions of Linux OS, but the distribution used for this project is Lenny(Debian Testing/Unstable).

TABLE OF CONTENTS

Contents

Page No.

1. INTRODUCTION
1.1 Free (or open source) software Free software is software that comes with a license that gives users certain rights. In particular, the right to use the software, to modify it, to obtain its source, and to pass it on (under the same terms). Notice that the term "free" is about rights, not money. The Free Software Foundation (creators of the GNU GPL) speaks of free in this context as in "free speech", not as in "no cost".

1.2 About KDE

KDE, or the K Desktop Environment, is a network transparent contemporary desktop environment for UNIX workstations. KDE seeks to fulfill the need for an easy to use desktop for UNIX workstations, similar to desktop environments found on Macintosh and Microsoft Windows operating systems. KDE is built with Trolltech's Qt toolkit which runs on most Unix and Unix-like systems, Mac OS X and Microsoft Windows. All releases of KDE 3 are built upon Qt 3, which was only released under the GPL for Linux and Unix-like operating systems, including Mac OS X. For that reason, KDE 3 is only available on Windows through ports involving an X server. KDE 4 is based on Qt 4 which is also released under the GPL for Windows and Mac OS X. Therefore KDE 4 applications can run natively on these operating systems as well. KDE aims to make easy-to-use programs without sacrificing features. KDE's Usability page states its goal as: "Working within the existing design goals of a system, usability efforts aim to make the implementations of these designs easier to use, faster to learn, more consistent and obvious, and generally more ergonomic for their target audience. the KDE project serves as an

umbrella project for many standalone applications and smaller projects that are based on KDE technology. These include KOffice, KDevelop, Amarok, K3b and many others.

1.3 About NRCFOSS:

National Resource Centre for Free/Open Source Software (NRCFOSS) aims to contribute to the growth of FOSS in India through Research and Development, Human Resource Development, Networking and Entrepreneurship Development, as well as serve as the reference point for all FOSS related activities in the country including the creation and maintenance of this national FOSS Portal. The National Resource Centre for Free/Open Source Software (NRCFOSS) is funded by the Department of Information Technology (DIT), Ministry of Communication and Information Technology (MCIT), Govt. of India, and is being managed jointly by the Chennai division of the Centre for Development of Advanced Computing(C-DAC) and AU-KBC Research Centre, Anna University, Chennai. C-DAC is an Autonomous Scientific Society of the DIT, Govt. of India and AU-KBC Research Centre is an Autonomous Research Centre of the Anna University.

1.4 About Qt:

Qt, by Trolltech, is a C++ toolkit for cross-platform GUI application development. Qt provides single-source portability across Microsoft Windows, Mac OS X, Linux, all major commercial Unix variants, and embedded Linux. On embedded Linux, the Qt API is available as Qt/Embedded. Qt provides application developers with all the functionality needed to build applications with state-of-the-art graphical user interfaces. Qt is fully object-oriented, easily extensible, and allows true component programming.

Since its commercial introduction in early 1996, Qt has formed the basis of many thousands of successful applications worldwide. Qt is also the basis of the popular KDE Linux desktop environment, a standard component of all major Linux distributions. Qt is supported on the following platforms: Microsoft Windows -- 98, NT 4.0, ME, 2000, and XP Unix/X11 -- Linux, Sun Solaris, HP-UX, HP Tru64 UNIX, IBM AIX, SGI IRIX and many others Mac OS X -- Mac OS X 10.2+ Embedded Linux -- Linux platforms with frame buffer support Trolltech supports the free software concept by providing the Qt Open Source Edition. Developers can use this edition of Qt to create free software, i.e. software that is licensed under the GNU GPL or a similarly recognized open source license. Trolltech's support of open source with the Qt Open Source Edition has enabled large successful software projects like KDE to thrive, with thousands of developers around the world using Qt Open Source Edition at no cost to them.

2. SOFTWARE REQUIREMENTS SPECIFICATION

2.1 INTRODUCTION This project aims at developing a picture editor. 2.1.1 Purpose This document describes the external behavior of the application. It also describes non-functional requirements, design constraints and other factors necessary to provide a complete and comprehensive description of the requirements for the software. The intended behavior of the system is clearly explained so that the communication gaps do not lead to misinterpretations of actual requirements. The requirements specified in this document are to be translated without any further assumptions from the analysts or developers side to consequently lead to the system with desired functionalities.

2.1.2 Scope of the system Our application provides an editor to the user for viewing and performing simple manipulations on images. It also provides some basic manipulations like inverting the pixels in an image; transforming an image; zooming in and out for detailed view; rotating and image; swapping the RGB components; performing fast fourier transforms for a sharper and more accurate image and to fit the image to the window size. The user interface is simple and appropriate.

2.1.3 Product features Image editor provides the following features to a user. Image viewing Image editor can load image formats supported by KDE. It correctly displays images with alpha channel, using the traditional checker board as a background to reveal transparency. It lets the user accurately control the way images are scaled: user can zoom in and out or automatically scale the image to fit the window. User can also rotate the images by an angle of 90 degrees to the left or right. Image manipulations Our Image editor does not try to replace your favorite image editor, so it only features the most simple image manipulations: rotation through mirroring and inverting pixels. When working with JPEG files, it performs lossless manipulations.

2.1.4 User Characteristics The application is for occasional photographers and single shot users, users who want to quickly view an image from a website or an email. The application supports inverting pixels in an image. Hence it can be used to create negative images. The application is not intended for professional photographers and digital artists.

The user need not have any inherent knowledge of Qt or Linux..The GUI is simple and easy to understand. It has been developed keeping in mind an average user.

2.1.5 Constraints The application is licensed under the GNU GPL. This is to ensure that the users enjoy the freedom guaranteed by the GPL. Users are entitled to: 1. Run this software for any purpose. 2. Obtain and study this software's source code, and adapt it to their needs. 3. Redistribute this software and its source code to others (under the same terms). 4. Improve or modify this software, and release these changes to the public.

These freedoms apply to all the source code for all the modules your software is based on. The freedoms also apply to any associated interface definition files, and even include the scripts and control files used to control compilation and installation of the executable; otherwise users could not exercise their rights.

2.1.6 Assumptions and dependencies The very minimum assumption made for this application is that the user would be running this application on a system which has Qt 4.0. This assumption has been made based on the fact that we require an X-server to successfully implement graphics.

2.1.7 Software Requirements The following are the Software requirements: Operating system Software : : Linux distributions like Sabayon, Debian (Etch/Unstable). Qt 4.0 (either as a binary or directly compiled from Source)

2.1.8 Hardware Requirements The following are the Hardware requirements: Processor RAM Hard Disc capacity : : : Pentium IV or any higher processor. 512 MB or higher. 80 GB or higher.

Additional requirements include an NVidia Sound and Graphics card.

3. DESIGN USING UML

3.1 An Overview of UML: The UML is a language for, Visualizing Specifying Constructing Documenting These are the artifacts of a software-intensive system. The embedded real-time software systems encountered in applications such as telecommunications, school systems, aerospace, and defense typically tends to be large and extremely complex. It is crucial in such systems that the software is designed with a sound architecture. A good architecture not only simplifies construction of the initial system, but also, readily accommodates changes forced by a steady stream of new requirements Visual modeling is a way of thinking about problems using models organized around real world ideas. Models are useful for understanding problems, communication with everyone involved with the project, modeling enterprises, preparing documentation and designing programs and database. Modeling promotes better understanding of requirements, cleaner designs and more maintainable systems. Models are abstractions that portraits the essentials of complex problem or structure by filtering out nonessential details, thus making the problem easier to understand.

help

print

exit

transform

swapcolors

end user

invert

open rotate

fit to window

zoom

Fig.3.1 Use case diagram for Image editor Use case diagram represents the relationship between various actors involved and the use cases related to the project.

User

Editor

Image Database

request to open an image displays the available options checks for image

displays file not found

found?

image returned for further actions

opens image for viewing

returns image

zoom? request to zoom in or out

zoom out

request to rotate the image left or right

zoom in

request to fit the image into window

rotate left/right?

rotate right rotate left

request to swap colors image fitted to window

request to invert pixels

colors swapped pixels inverted

request to transform

fast fourier transform applied

changed image for viewing

Fig.3.2 Activity Diagram The above figure represents the flow of activity in this project.

QObject objectname objectname() connect() disconnect() blocksignals() connectNotify() disconnectNotify()

QScrollArea scrollarea QScrollArea() QSetWidget() widgetresizeable()

QMainWindow objectname savestate() restorestate()

QApplication object instance()

QAction action addAction()

QScrollBar horizontal scrollbar vertical scrollbar QLabel label new QLabel() setAlignment() setIndent() setPixmap() setPicture() resize() setBackgroundRole() setFixedSize() QMenu menu name addMenu() addActions() addSeperator() clear() removeActions() QScrollBar()

ImageEditor imagelabel open print exit zoomIn zoomOut rotateLeft rotateRight normalSize fitToWindow about aboutQt scrollarea copy save saveAs transform swapcolors invertpixels ImageEditor()

Fig.3.3 Class Diagram The above figure represents the various classes included and the inter dependencies between them.

4. IMPLEMENTATION
4.1 Classes: The important classes used in this application are as follows: QAction: The QAction class provides an abstract user interface action that can be inserted into widgets. Actions can be added to menus and toolbars, and will automatically keep them in sync. Actions can be created as independent objects, but they may also be created during the construction of menus; as in our project. Once a QAction has been created it should be added to the relevant menu and toolbar, and then connected to the slot which will perform the action. QLabel: The QLabel widget provides a text or image display. QLabel is used for displaying text or an image. No user interaction functionality is provided. The visual appearance of the label can be configured in various ways, and it can be used for specifying a focus mnemonic key for another widget. A QLabel can contain any of the following content types: Plain text Rich text A pixmap A movie A number Nothing : : : : : : Pass a QString to setText(). Pass a QString that contains rich text to setText(). Pass a QPixmap to setPixmap(). Pass a QMovie to setMovie(). Pass an int or a double to setNum(), which converts the number to plain text. The same as an empty plain text. This is the default. Set by Clear(). When the content is changed using any of these functions, any previous content is cleared.

QMenu: The QMenu class provides a menu widget for use in menu bars, context menus, and other popup menus. A menu widget is a selection menu. It can be either a pull-down menu in a menu bar or a standalone context menu. Pull-down menus are shown by the menu bar when the user clicks on the respective item or presses the specified shortcut key. Context menus are usually invoked by some special keyboard key or by right-clicking. They can be executed either asynchronously with popup() or synchronously with exec(). Menus can also be invoked in response to button presses; these are just like context menus except for how they are invoked. A menu consists of a list of action items. Actions are added with addAction(). An action is represented vertically and rendered by QStyle. In addition, actions can have a text label, an optional icon drawn on the very left side, and shortcut key sequence. There are three kinds of action items: separators, actions that show a submenu, and actions that perform an action. Separators are inserted with addSeparator(). For submenus use addMenu(). All other items are considered action items. QScrollArea: The QScrollArea class provides a scrolling view onto another widget. A scroll area is used to display the contents of a child widget within a frame. If the widget exceeds the size of the frame, the view can provide scroll bars so that the entire area of the child widget can be viewed.

QScrollBar: The QScrollBar widget provides a vertical or horizontal scroll bar. A scroll bar is a control that enables the user to access parts of a document that is larger than the widget used to display it. It provides a visual indication of the user's current position within the document and the amount of the document that is visible. Scroll bars are usually equipped with other controls that enable more accurate navigation. QMainWindow: The QMainWindow class provides a main application window. QMainWindow provides a main application window, with a menu bar, tool bars, dock widgets and a status bar around a large central widget, such as a text edit, drawing canvas or QWorkspace. QPrinter: The QPrinter class is a paint device that paints on a printer. On Windows or Mac OS X, QPrinter uses the built-in printer drivers. On X11, QPrinter generates postscript and sends that to lpr, lp, or another printProgram(). QPrinter can also print to any other QPrintEngine. QPrinter supports a number of settable parameters, most of which can be changed by the end user through a QAbstractPrintDialog print dialog. In general, QPrinter passes these functions onto the underlying QPrintEngine. The most important parameters are: setOrientation() setPageSize() setResolution() : : : tells QPrinter which page orientation to use. tells QPrinter what page size to expect from the printer. tells QPrinter what resolution you wish the from the printer to provide in dots per inch.

setFullPage()

tells QPrinter whether you want to deal with the full page or just with the part the printer can draw on. The default is false, so that by default you should be able to paint on (0,0). If true the origin of the coordinate system will be in the top left corner of the paper and most probably the printer will not be able to paint something there due to it's physical margins.

setNumCopies()

tells QPrinter how many copies of the document it should print.

QFile: The QFile class provides an interface for reading from and writing to files. QFile is an I/O device for reading and writing text and binary files and resources. A QFile may be used by itself or, more conveniently, with a QTextStream or QDataStream. The file name is usually passed in the constructor, but it can be set at any time using setFileName().The file is opened with open(), closed with close(), and flushed with flush(). Data is usually read and written using QDataStream or QTextStream, but you can also call the QIODevice-inherited functions read(), readLine(), readAll(), write(). QFile also inherits getChar(), putChar(), and ungetChar(), which work one character at a time. The size of the file is returned by size(). You can get the current file position using pos(), or move to a new file position using seek(). If you've reached the end of the file, atEnd() returns true.

QFileDialog: The QFileDialog class provides a dialog that allows users to select files or directories. The QFileDialog class enables a user to traverse the file system in order to select one or many files or a directory. QMessageBox: The QMessageBox class provides a modal dialog with a short message, an icon, and some buttons. Message boxes are used to provide informative messages and to ask simple questions. QMessageBox provides a range of different messages, arranged roughly along two axes: severity and complexity.

4.2 Image Editor Class Definition: class { Q_OBJECT public: ImageEditor(); private void void bool bool void void slots: open(); copy(); save(); saveAs(); print(); zoomIn(); ImageEditor : public QMainWindow

void void void void void void void void void private: bool void void void void void QLabel QScrollArea double QPrinter QAction QAction QAction QAction QAction QAction QAction scaleImage(double adjustScrollBar(QScrollBar *scrollBar, double saveFile(const QString

zoomOut(); rotateLeft(); rotateRight(); swapcolors(); transform(); invertpixels(); normalSize(); fitToWindow(); about();

&fileName); createActions(); createMenus(); updateActions(); factor); factor); *imageLabel; *scrollArea; scaleFactor; printer; *openAct; *copyAct; *saveAct; *saveAsAct; *printAct; *exitAct; *zoomInAct;

QAction QAction QAction QAction QAction QAction QAction QAction QAction QAction QMenu QMenu QMenu QMenu };

*zoomOutAct; *rotateLeftAct; *rotateRightAct; *swapcolorsAct; *transformAct; *invertpixelsAct; *normalSizeAct; *fitToWindowAct; *aboutAct; *aboutQtAct; *fileMenu; *viewMenu; *editMenu; *helpMenu;

The ImageViewer class inherits from QMainWindow. We re-implement the constructor, and create several private slots to facilitate the menu entries. In addition we create four private functions. We use createActions() and createMenus() when constructing the ImageViewer widget. We use the updateActions() function to update the menu entries when a new image is loaded, or when the Fit to Window option is toggled. The zoom slots use scaleImage() to perform the zooming. In turn, scaleImage() uses adjustScrollBar() to preserve the focal point after scaling an image. The rotate slots use mirrored() to perform the rotation.

4.3 ImageViewer Class Implementation ImageViewer::ImageViewer() { imageLabel = new QLabel; imageLabel->setBackgroundRole(QPalette::Base); imageLabel->setSizePolicy(QSizePolicy::Ignored, QSizePolicy::Ignored); imageLabel->setScaledContents(true); scrollArea = new QScrollArea; scrollArea->setBackgroundRole(QPalette::Dark); scrollArea->setWidget(imageLabel); setCentralWidget(scrollArea); createActions(); createMenus(); setWindowTitle(tr("Image Viewer")); resize(500, 400); }

In the constructor we first create the label and the scroll area. We set imageLabel's size policy to ignored, making the users able to scale the image to whatever size they want when the Fit to Window option is turned on. Otherwise, the default size policy (preferred) will make scroll bars appear when the scroll area becomes smaller than the label's minimum size hint.

We ensure that the label will scale its contents to fill all available space, to enable the image to scale properly when zooming. We make imageLabel the scroll area's child widget, and we make scrollArea the central widget of the QMainWindow. At the end we create the associated actions and menus, and customize the ImageViewer's appearance. In the open() slot, we show a file dialog to the user. The easiest way to create a QFileDialog is to use the static convenience functions. QFileDialog::getOpenFileName() returns an existing file selected by the user. If the user presses Cancel, QFileDialog returns an empty string. Unless the file name is a empty string, we check if the file's format is an image format by constructing a QImage which tries to load the image from the file. If the constructor returns a null image, we use a QMessageBox to alert the user. We implement the zooming slots using the private scaleImage() function. We set the scaling factors to 1.25 and 0.8, respectively. These factor values ensure that a Zoom In action and a Zoom Out action will cancel each other (since 1.25 * 0.8 == 1), and in that way the normal image size can be restored using the zooming features. We implement the about() slot to create a message box describing what the example is designed to show. void ImageViewer::createActions() { openAct = new QAction(tr("&Open..."), this); openAct->setShortcut(tr("Ctrl+O")); connect(openAct, SIGNAL(triggered()), this, SLOT(open())); printAct = new QAction(tr("&Print..."), this); printAct->setShortcut(tr("Ctrl+P")); printAct->setEnabled(false);

connect(printAct, SIGNAL(triggered()), this, SLOT(print())); exitAct = new QAction(tr("E&xit"), this); exitAct->setShortcut(tr("Ctrl+Q")); connect(exitAct, SIGNAL(triggered()), this, SLOT(close()));

zoomInAct = new QAction(tr("Zoom &In (25%)"), this); zoomInAct->setShortcut(tr("Ctrl++")); zoomInAct->setEnabled(false); connect(zoomInAct, SIGNAL(triggered()), this, SLOT(zoomIn())); zoomOutAct = new QAction(tr("Zoom &Out (25%)"), this); zoomOutAct->setShortcut(tr("Ctrl+-")); zoomOutAct->setEnabled(false); connect(zoomOutAct, SIGNAL(triggered()), this, SLOT(zoomOut())); normalSizeAct = new QAction(tr("&Normal Size"), this); normalSizeAct->setShortcut(tr("Ctrl+S")); normalSizeAct->setEnabled(false); connect(normalSizeAct, SIGNAL(triggered()), this, SLOT(normalSize())); fitToWindowAct = new QAction(tr("&Fit to Window"), this); fitToWindowAct->setEnabled(false); fitToWindowAct->setCheckable(true); fitToWindowAct->setShortcut(tr("Ctrl+F")); connect(fitToWindowAct, SIGNAL(triggered()), this, SLOT(fitToWindow())); aboutAct = new QAction(tr("&About"), this); connect(aboutAct, SIGNAL(triggered()), this, SLOT(about()));

aboutQtAct = new QAction(tr("About &Qt"), this); connect(aboutQtAct, SIGNAL(triggered()), qApp, SLOT(aboutQt())); } In the private createAction() function, we create the actions providing the application features. We assign a short-cut key to each action and connect them to the appropiate slots. We only enable the openAct and exitAxt at the time of creation; the others are updated once an image has been loaded into the application. In addition we make the fitToWindowAct checkable. void ImageViewer::createMenus() { fileMenu = new QMenu(tr("&File"), this); fileMenu->addAction(openAct); fileMenu->addAction(printAct); fileMenu->addSeparator(); fileMenu->addAction(exitAct); viewMenu = new QMenu(tr("&View"), this); viewMenu->addAction(zoomInAct); viewMenu->addAction(zoomOutAct); viewMenu->addAction(normalSizeAct); viewMenu->addSeparator(); viewMenu->addAction(fitToWindowAct); helpMenu = new QMenu(tr("&Help"), this); helpMenu->addAction(aboutAct); helpMenu->addAction(aboutQtAct);

menuBar()->addMenu(fileMenu); menuBar()->addMenu(viewMenu); menuBar()->addMenu(helpMenu); } In the private createMenu() function, we add the previously created actions to the File, View and Help menus. The QMenu class provides a menu widget for use in menu bars, context menus, and other popup menus. The QMenuBar class provides a horizontal menu bar that consists of a list of pull-down menu items. So at the end we put the menus in the
ImageViewer's

menu bar which we retrieve with the QMainWindow::menuBar()

function. The private updateActions() function enables or disables the Zoom In, Zoom Out and Normal Size menu entries depending on whether the Fit to Window option is turned on or off. In scaleImage(), we use the factor parameter to calculate the new scaling factor for the displayed image, and resize imageLabel. Since we set the scaledContents property to true in the constructor, the call to QWidget::resize () will scale the image displayed in the label. We also adjust the scroll bars to preserve the focal point of the image. At the end, if the scale factor is less than 33.3% or greater than 300%, we disable the respective menu entry to prevent the image pixmap from becoming too large, consuming too many resources in the window system.

The following function adjusts the scrollbar whenever we zoom in or out. void ImageViewer::adjustScrollBar(QScrollBar *scrollBar, double factor) { scrollBar->setValue(int(factor * scrollBar->value() + ((factor - 1) * scrollBar->pageStep()/2))); }

5. TESTING AND RESULTS

5.1 Testing Software testing is the process used to assess the quality of computer software. Software testing is an empirical technical investigation conducted to provide stakeholders with information about the quality of the product or service under test , with respect to the context in which it is intended to operate. This includes, but is not limited to, the process of executing a program or application with the intent of finding software bugs. Quality is not an absolute; it is value to some person. With that in mind, testing can never completely establish the correctness of arbitrary computer software; testing furnishes a criticism or comparison that compares the state and behavior of the product against a specification. The software faults occur through the following process. A programmer makes an error (mistake), which results in a defect (fault, bug) in the software source code. If this defect is executed, in certain situations the system will produce wrong results, causing a failure. Not all defects will necessarily result in failures. For example, defects in a dead code will never result in failures. A defect can turn into a failure when the environment is changed. There are many approaches to software testing. Reviews, walkthroughs or inspections are considered as static testing, whereas actually running the program with a given set of test cases in a given development stage is referred to as dynamic testing. Software testing is used in association with verification and validation: Verification: Have we built the software right (i.e., does it match the specification)? Validation: Have we built the right software (i.e., is this what the customer wants)?

5.1.1 Testing methods Software testing methods are traditionally divided into black box testing and white box testing. These two approaches are used to describe the point of view that a test engineer takes when designing test cases. Black box testing treats the software as a black-box without any understanding of internal behavior. It aims to test the functionality according to the requirements. Thus, the tester inputs data and only sees the output from the test object. This level of testing usually requires thorough test cases to be provided to the tester who then can simply verify that for a given input, the output value (or behavior), is the same as the expected value specified in the test case. Black box testing methods include: equivalence partitioning, boundary value analysis, all-pairs testing, fuzz testing, model-based testing, traceability matrix etc. White box testing, however, is when the tester has access to the internal data structures, code, and algorithms. White box testing methods include creating tests to satisfy some code coverage criteria. For example, the test designer can create tests to cause all statements in the program to be executed at least once. Other examples of white box testing are mutation testing and fault injection methods. White box testing includes all static testing. White box testing methods can also be used to evaluate the completeness of a test suite that was created with black box testing methods. This allows the software team to examine parts of a system that are rarely tested and ensures that the most important function points have been tested. Two common forms of code coverage are function coverage, which reports on functions executed and statement coverage, which reports on the number of lines executed to complete the test. In recent years the term grey box testing has come into common usage. This involves having access to internal data structures and algorithms for purposes of designing the test cases, but testing at the user, or black-box level. Manipulating input data and

formatting output do not qualify as grey-box because the input and output are clearly outside of the black-box we are calling the software under test. This is particularly important when conducting integration testing between two modules of code written by two different developers, where only the interfaces are exposed for test. Special methods exist to test non-functional aspects of software. Performance testing checks to see if the software can handle large quantities of data or users. Usability testing is needed to check if the user interface is easy to use and understand. Testing can be done on the following levels: Unit testing tests the minimal software component, or module. Each unit (basic component) of the software is tested to verify that the detailed design for the unit has been correctly implemented. In an object-oriented environment, this is usually at the class level, and the minimal unit tests include the constructors and destructors. Integration testing exposes defects in the interfaces and interaction between integrated components (modules). Progressively larger groups of tested software components corresponding to elements of the architectural design are integrated and tested until the software works as a system. System testing tests a completely integrated system to verify that it meets its requirements. System integration testing verifies that a system is integrated to any external or third party systems defined in the system requirements.

Before shipping the final version of software, alpha and beta testing are often done additionally: Alpha testing is simulated or actual operational testing by potential users/customers or an independent test team at the developers' site. Alpha testing is often employed for off-the-shelf software as a form of internal acceptance testing, before the software goes to beta testing. Beta testing comes after alpha testing. Versions of the software, known as beta versions, are released to a limited audience outside of the programming team. The software is released to groups of people so that further testing can ensure the product has few faults or bugs. Sometimes, beta versions are made available to the open public to increase the feedback field to a maximal number of future users. Finally, acceptance testing can be conducted by the end-user, customer, or client to validate whether or not to accept the product. Acceptance testing may be performed as part of the hand-off process between any two phases of development.

5.2 Results Opening an image

Zoom operations

Inverting pixels

Swapping Colors

Original image

After performing swap and invert

Print dialog box

About Dialog Box

Implementing Save

CHAPTER 6: CONCLUSIONS
The application has been tested and found to be free of bugs. Since this project is licensed under GPL, further enhancements to the code are always appreciated. As of now, the editor is limited to displaying a single picture at a time. We would like to implement thumbnail view for this application, enabling users to view and manipulate multiple pictures at once. Another limitation that we would like to overcome is to integrate the editor with a web browser for additional features. We would also like to add a tree view of all the available files and folders for easy accessing .

BIBLIOGRAPHY
1. Qt 4.0 Reference documentation (Open source edition) available online for reference at http://doc.trolltech.com/4.0/index.html 2. C++ GUI Programming with Qt 3 by Jasmin Blanchette and Mark Summerfield, ISBN 0-13-124072-2. 3. The Icon Book by William Horton, ISBN 0-471-59900-X. 4. GUI Design Handbook by Susan Fowler, ISBN 0-07-059274-8. 5. Design Patterns - Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson, and Vlissides.

APPENDIX More about Qt:

Qt Core features: 1. Signals and Slots 2. Object Model 3. Layout Management 4. Plugin System Signals and Slots: Signals and slots are used for communication between objects. The signals and slots mechanism is a central feature of Qt and probably the part that differs most from the features provided by other frameworks. These signals and slots help us enable communication between Widgets or in other words, objects. Older toolkits achieve this kind of communication using callbacks. A callback is a pointer to a function, so if you want a processing function to notify you about some event you pass a pointer to another function (the callback) to the processing function. The processing function then calls the callback when appropriate. Callbacks have two fundamental flaws: Firstly, they are not type-safe. Secondly, the callback is strongly coupled to the processing function since the processing function must know which callback to call.

The signals and slots mechanism is type safe: The signature of a signal must match the signature of the receiving slot. Since the signatures are compatible, the compiler can help us detect type mismatches. Signals and slots are loosely coupled: A class which emits a signal neither knows nor cares which slots receive the signal. Signals are emitted by objects when they change their state in a way that may be interesting to other objects. This is all the object does to communicate. It does not know or care whether anything is receiving the signals it emits. This is true information encapsulation. Slots can be used for receiving signals, but they are also normal member functions. Just as an object does not know if anything receives its signals, a slot does not know if it has any signals connected to it. This ensures that truly independent components can be created.

You can connect as many signals as you want to a single slot, and a signal can be connected to as many slots as you need. It is even possible to connect a signal directly to another signal. Together, signals and slots make up a powerful component programming mechanism. Object Model: The standard C++ object model provides very efficient runtime support for the object paradigm. But its static nature is inflexible in certain problem domains. Graphical user interface programming is a domain that requires both runtime efficiency and a high level of flexibility. Qt provides this, by combining the speed of C++ with the flexibility of the Qt Object Model. Qt adds these features to C++: --a very powerful mechanism for seamless object communication called signals and slots --query able and designable object properties --powerful events and event filters --contextual string translation for internationalization --sophisticated interval driven timers that make it possible to elegantly integrate many tasks in an event-driven GUI --hierarchical and query able object trees that organize object ownership in a natural way guarded pointers (QPointer) that are automatically set to 0 when the referenced object is destroyed, unlike normal C++ pointers which become dangling pointers when their objects are destroyed --a dynamic cast that works across library boundaries. Layout Management: The Qt layout system provides a simple and powerful way of specifying the layout of child widgets. By specifying the logical layout once, we can do the following:

--Position the child widgets. --Assign sensible default and minimum sizes for windows. --Handle window resizing. --Provide automatic update when contents change: --Font size, text or other contents of child widgets. --Hiding or showing a child widget. --Removal of child widgets. Layouts can be implemented in horizontal, vertical and grid formats. The above mentioned features can be implemented using hand-written code. Horizontal, Vertical, and Grid Layouts The easiest way to give you widgets a good layout is to use the built-in layout managers: QHBoxLayout, QVBoxLayout, and QGridLayout. These classes inherit from QLayout, which in turn derives from QObject (not QWidget). They take care of geometry management for a set of widgets. To create more complex layouts, you can nest layout managers inside each other. A QHBoxLayout lays out widgets in a horizontal row, from left to right (or right to left for right-to-left languages).

A QVBoxLayout lays out widgets in a vertical column, from top to bottom.

A QGridLayout lays out widgets in a two-dimensional grid. Widgets can occupy multiple cells.

When you use a layout, you don't need to pass a parent when constructing the child widgets. The layout will automatically reparent the widgets (using QWidget::setParent ()) so that they are children of the widget on which the layout is installed. Widgets in a layout are children of the widget on which the layout is installed, not of the layout itself. Widgets can only have other widgets as parent, not layouts. Plugin system: Qt provides two APIs for creating plugins: --A higher-level API for writing extensions to Qt itself: custom database drivers, image formats, text codecs, custom styles, etc. --A lower-lever API for extending Qt applications. This enables developers to use Qt effectively while developing code for plugin based applications. This feature is being prominently used in KDEs Krita. Qt provides unending support to the following technologies: --Multithreaded Programming --Main Window Architecture --Rich Text Processing --Model/View Programming --Network Module --OpenGL Module

--SQL Module --XML Module qmake is a tool from Trolltech that helps simplify the build process for development

qmake

project across different platforms. qmake automates the generation of Makefiles so that only a few lines of information are needed to create each Makefile. qmake can be used for any software project, whether it is written in Qt or not. generates a Makefile based on the information in a project file. Project files are

qmake

created by the developer, and are usually simple, but more sophisticated project files can be created for complex projects. qmake contains additional features to support development with Qt, automatically including build rules for moc and uic. qmake can also generate projects for Microsoft Visual studio without requiring the developer to change the project file.