DNA

Dynamic Neural Art - Requirements Document
Version 1.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. This relates to the Domisilica projects. 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.

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 exact generation process is yet to be determined, but here is an example:

The top three images are kept in the evaluation pool, and the other six images are replaced by new pictures created from parameters similar to those of the top three. Eventually the program will learn to produce cool pictures, and by placing them on your living room wall (or kitchen) you will enjoy the comforts of you modern domicile that much 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. We considered using Java, but 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).

We still have to research the generation algorithms, as well as those for the fractals, but they all exist. There are two similar projects, International Interactive Genetic Art and John Mount's International Interactive Genetic Art II from which we have drawn ideas. We discussed how this project could have a future not only as an added feature of Domisilica, also 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.

At this point we still have to iron out the details as to how many initial selections a user needs to make. We have decided that nine fractal images will be used, but that may change due to the generation requirements. We will show them in thumbnail (small) view and when a user clicks on a particular image it expands to show a more detailed view.

On the output end, we envision a framed screen that hangs on the wall. Every hour (or sooner) a new image will be displayed. A mockup is shown below.

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. User Interface - The user has to be able to select his/her top choices from a group of images. The web page must have directions explaining the process. 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. CGI script that saves a user's choices 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 Requirement

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. Usability - The voting web page has to be easy to use in that it limits the user to three selections. There are clearly present 'submit', and 'reset' buttons. There should be a brief set a directions explaining how the voting process works and a link to the "winning" page.

  3. Security - There are some security issues in dealing with the CGI scripts. By using the internal server and a mail filter, we are able to perform our project with minimal security risk.

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 could 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 - It could be that we have overestimated the size and scope of this project. This could 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.


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