DNA

Dynamic Neural Art - Requirements Document
Version 2.0


Spring Quarter 1997 Project Team:
Project Sponsor: Alp Sendil(Manager)
Gregory Abowd Enda Sullivan (Architect) & (QA)
Bob Sumner (Programmer)
Lynn Bacher (Technical Writer)

Table of Contents


Project Description of Target System

We like cool images. Cool images are useful. By cool, we mean something that is aesthetic, pleasing to look at, or causes a person to say, "wow, cool picture dude!" They can be soothing paintings on your living room wall or interesting backgrounds on your computer screen. We want to create a program that can learn what a cool image is, and then create them. Genetic Art, as we call it, may be displayed on your refrigerator, or on an LCD in your living room; just add a frame to go around the screen. The picture would periodically update its self, creating new cool images. This relates to the Domisilica project where computers are integrated into the home.

The criteria used to evaluate "cool" would come from an application that we place on the World Wide Web (see demo). Our program on the web would display nine images, asking the user to select their top choices. Periodically, the 'votes' would be counted up and the 'coolest' image would be selected for your viewing pleasure. The generation process takes the users' top three choices and creates nine more images. Of these, a "winner" is chosen and is displayed on a separate page. The program "learns" from these choices to produce cool pictures, and by placing them on your living room wall (or kitchen) you will enjoy the comforts of you modern domicile even more.

We decided to use fractals for our cool images. The project will require some knowledge of CGI/Perl and HTML for the evaluating the criteria and also requires C to construct the fractals. Since the pictures take some time to generate (a minute or two) we decided that C would be the best developing tool for the job. The images will be created and saved to GIF format, then transferred to the web server, where they may be judged. The update will occur periodically (once every hour or less).

We will be using a program called xFractInt to generate our fractal images. There are two similar projects, International Interactive Genetic Art and John Mount' s International Interactive Genetic Art II from which we have drawn ideas. This project could have a future not only as an added feature of Domisilica, but also ccould be used in marketing schemes to generate images based on social profiles.

Scenario Descriptions

Storyboarding

During our first meeting there were many prototypes drawn on the white board. This was mainly just brainstorming on our part. We needed an interesting interface for our users. We knew there needed to be a selection of images. We also needed some way t o show the users selections. From the rough sketches, you can see some of our earliest ideas.

From these initial efforts Enda was able to put together a prototype. We showed it to a few people unrelated to our project to get some objective opinions. While they liked the general layout of the images, using frames on either side made it confusing as to the intent. They images did not fit onto the initial screen very well. That and difficulties in the selection methods made us evolve the user interface to the current prototype.

On the voting page, the user gets nine images from which to choose three favorites. They have the option of resetting all of their choices. They ar restricted to making only three selections. They do have they ability to cast all of their votes toward one image, though.

After the user clicks on the "submit" button, the votes are stored in files for each image. The user sees a new screen pop up. This screen tells them how many more votes are needed until a new set of images is generated.

After five sets of votes have been received, the image generation process starts. A screen appears preventing the user from submitting votes. In the future, we may have a graphical version showing the generation progress.

Once the generation is complete the main voting page returns with new selection available to be judged. At the same time, the "winning" image (the one with the most votes) is sent to a separate webpage where it can be displayed for viewing. We envision a framed screen that hangs on the wall. Every hour (or sooner) a new image will be displayed.

Functional Requirements

The following requirements are listed in order of importance to our project with the highest priority tasks listed first. While certain parts of our project are being developed independently (see our schedule of activities) , the lower numbers are dependent on the higher priority processes being implemented.

  1. Generating the Fractals - The highest priority for our project was the determination of how the fractal images will be generated. There are many different ways that images can be drawn, but we needed a system that would allow us to guide how a image would look based on a set of parameters. These parameters will be used later in the learning algorithm. They also have to be extracted from the images that the user chooses from the web page.

    1. Code that generates images based on explicit parameters
    2. Incorporating color into the images

  2. Image Selection by the User - The user has to be able to select his/her top choices from a group of images. The web page must have directions explaining how to make the selections. After the selection, the choices must be saved and returned to the learning algorithm for the next generation of images.

    1. A web page that allows a user to select, deselect, and reset their choices
    2. The user's choices are saved in a way that can be used by the learning algorithm
    3. Thumbnail sketches can be expanded to show a more detailed view of an image

  3. The Learning Algorithm - The learning algorithm is put at lower priority due to the fact that it is entirely dependent on the existence of a user interface and the ability to generate the fractals in the first place.

    1. Code that can take a multitude of selections from users and generate a new set of parameters for the next generation of images

Non-Functional Requirements

Non-functional requirements deal with the environment in which our system evolves. The following list show our top three non-functional requirements from highest to lower priority.

  1. Reasonable Turnaround Time - We shall be able to generate a new set of fractals after every five votes. It should take no more than five minutes to update the voting web page and load the new winning image.

  2. Limited Choices - The voting web page has to be easy to use in that it limits the user to three selections. There should be buttons that only allow one selection of their first, second, and third choices. There are clearly present 'submit', and 'reset' buttons.

  3. Clear and Concise Instructions - There should be a brief set a directions explaining how the voting process works with a link to the "winning" page. The user should be able to understand how to submit their choices without consulting outside help. This will be accomplished by a brief set of instructions.

Development and Target Platforms

There are three sections of our project that have development and implementation platforms: the fractal generation, vote processing, and the web pages.

Risk Analysis

The following detail some of the risks we perceive with our project. They are listed in order of importance.

  1. Network Failure - We are dealing with several different systems in our project. The three that concern us are the web server, the fractal generation machine, and the mail server. Any or all of these systems could go down (although unlikely). The consequences are as follows:

    The worst that can happen here is that there is a time delay in our process. There should be no data loss. If there is, the generation process simply starts again with a new set of parameters. After there have been five votes, a "Please wait" page is installed where the "Voting page" normally located. If any of the machines go down, this page will just stay up a little longer.

  2. File Corruption - Since we are using the College of Computing's internal server there is a chance that our image files can be compromised or corrupted by other users. Since we keep backups of our scripts and fractal generation programs, the worst that could happen is that we lose our voting results and/or images. Once again the generation process simply starts with a new set of parameters.

  3. Team Member Loss - While losing a team member to an emergency or illness would not be easy, we could still continue the project at this point. It would entail a complete rescheduling of the project and we might not be able to deliver on time. We have tried to limit this damage by keeping everyone informed of the stages of completion of the project.

  4. Overestimation - We may have overestimated the size and scope of this project. This would mean that we are either unable to meet our requirements or schedule. By closely monitoring our own progress, we hope to avoid this altogether. We frequently go over our schedule to see that we are on track and up to date. If we were to go off schedule, we could lose some of our functionality, i.e. the color integration. By doing this we could save time in coding and testing, and at least deliver a working prototype. If possible, we could then reschedule more time and finish the product as originally intended.


Document Revision History

1 Date:5/1/97
Name(s):Lynn Bacher - Technical Writer
Description of revision:Update to the requirements document. Requirements Document 1.1 has been updated to include the additional data suggested by the grading criteria.

DNA Home Page
Last Modified 5/1/97 -- C. Lynn Bacher (lynn@cc.gatech.edu)