The final project teams a computer scientist with a natural scientist to create a custom visualization for a specific data set and set of visualization goals. Ideally, this data set will be one that the natural science student (or one of their colleagues) is interested in studying. Also, the visualization goals and data set should be something that cannot be done by simply loading the data into ParaView, VisTrails, or VTK and running a few standard modules together; the problem should be hard enough or different enough that it requires new design and implementation (this is like the degree-of-difficulty score in diving competitions).
There are three major parts to the project: visualization goals specification, visualization system development, and visualization system evaluation. Each will be described as part of the final written report on the project (drafts will be due earlier as well). The format of the write-up should be in the style of a Case Study (although considerably more detailed than those found in proceedings); projects that reveal particularly fruitful insights could be written up in the spring for the IEEE Visualization conference or other relevant venues.
This is the problem statement. It should include all information relevant to the description of the problem that is being investigated. This includes, but is not necessarily limited to the following:
The approaches to be taken to visualize the data, and the encoding of that design into a visualization system.
System design: Describe why the particular display channels are being chosen for this data set and set of tasks. Describe how each question posed in the visualization goals specification is being addressed by the visualization design. What display channels will convey information towards each of the goals (e.g.: height field carries height information and color carries conductance; direct volume rendering conveys density information and haptic display conveys density gradient; geometric model conveys context and slices textured with field-tracing lines convey magnetic field). What sort of interpolation is being done on the data? What is being done about missing values, if any? What legends will be present to help the user quantitatively estimate values? What color map is being used and why?
Two Designs: It is important to not let concerns over what you think you will be able to implement constrain your design. The above description should present the ideal visualization design for the data and questions you have, regardless of whether it can be fully implemented during the semester. If it is the case that you will not be able to implement the ideal visualization design this semester, then describe the actual system that you intend to implement in a separate section.
Include screen shots of any prototyping you have done on the visualization, or scanned images of visualizations using techniques that are similar to those you plan to use.
For the final version, include a discussion of how you might design the system differently the next time (based on your critique of the technique done in homework).
System Implementation: Describes how the design is turned into a working system. What toolkits are being used (AVS Express, VTK, openDX, Matlab, etc.), and what underlying libraries and languages are being used (openGL, GHOST, C++, etc.). What display hardware and input devices are being used? What computation and image-generation hardware is being used? Provide a high-level description of the program modules and how they work together. List or describe the algorithms that were used or developed for the visualization (marching cubes, Euler integration, color space transformations). The level of description should be adequate to enable a computer science student who is not a visualization expert to reproduce the work.
Include screen shots to show features of the the visualization system. Include lessons learned along the way (blind alleys that you tried before coming to the final implementation, things that worked better than you expected, interesting things you found out that you didn't expect). Include a discussion of how you might implement the system differently the next time.
How well does it work in practice? This will be investigated in two parts, a formal evaluation using a data set that is constructed just for testing, and an informal description of how the system worked for the intended user on their data set.
Formal evaluation on test data: This is not a formal user study (which would involve a number of users performing a set of tasks and include statistical analysis of their performance using the system). It is rather a test of the system by a single person who is not one of the system's authors to see if it meets its goals. It can be performed on either the actual data from the client or on a special data set designed to test its effectiveness (you get more points the more difficult it is to reach the goal using much simpler visualization or even computational techniques). The goal of the visualization should be the primary goal of the client (you get extra points if the secondary and further goals are also tested). The person testing the system is not allowed to have seen the test data set before they explore it using the visualization system. They are to be given written instructions and sent off to run the test without further interaction with the system designers (the designers can have left the application running with the data set loaded, but cannot preset the visualization parameters to reveal the goal). Both the written instructions and a screen shot of the running application as the person first saw it are to be included in the final report. The client can be the person testing the system, but then the data set must not be the one they gave the team (unless they haven't seen it before). Include the person's responses, and a discussion of how well they met the goals. Include quotes from them on their reaction to how easy it was to use the system, and their suggestions for improvements. This evaluation can be done at any point during the design process (it can be done on a prototype design to help improve the system for the final design, or it can be done on the final design). You get more points if they are able to achieve the goals; you also get more points if you are able to incorporate their suggestions into the final implementation.
Informal evaluation on real data: Include new knowledge (if any) that the client gained using your system, and speculate on why the system was able to bring it to light. Include anecdotal descriptions of what your system does better (and what it does worse) than the analysis techniques that were being applied beforehand. Include quotes from the client describing their reaction to the system. Include a picture of the client using the system. The client can certainly be shown the early prototypes (and should be!) and allowed to give feedback on the design. Be careful not to get caught in the trap of doing the visualization exactly like it has always been done in the client's particular field.
Within a team: The natural scientist is primarily responsible for the visualization goals specification and the visualization system evaluation; they will present these and write this section of the final project report. The computer scientist is primarily responsible for the implementation of the visualization system (both are responsible for design); they will present these and write this section of the final project report.
It is expected that there will be a lot of interaction and discussion between the team members; each should freely provide input to all parts of the project. This process works best when there is engagement and interest from both sides. It works best when there are a number of iterations in the system development itself (development of prototype, evaluation, ideas for improvements). Team members should freely perform their own evaluation as the system evolves (separate from the final formal evaluation process). The goal is for you to work together to produce a useful visualization system for the data and task at hand. In the context of this course, the natural scientist will have a lot of training on the appropriate design for the visualization system and so should participate heavily in the design.
This exercise is primarily a team effort, and it will be graded accordingly. An overall grade will be assigned for the project and its evaluation. Individual grades will then be assigned; these grades will be at most one grade-step away from the overall grade (P to P+ is one grade step, A- to B+ is one grade step).
Between teams, use of external resources: The way progress is made in academic disciplines is for new teams to build on the work of earlier teams, giving credit to the source. It is expected that teams will make use of all available externally-developed libraries and toolkits to help implement the visualizations. It is not an honor code violation in this project to use any outside help, so long as proper credit is given in the acknowledgments or references section of the document. That said, you get extra points for succeeding at a project that requires more of a stretch beyond what is available from existing resources. You'll get almost no points for "We used team A's visualization system and formal analysis results (as presented by them just a minute ago) and applied it to our client's data set." Two different teams can get full points for applying different techniques to the same type of data and having each of their techniques meet the goals of the clients (they would not be in competition with each other any more than with teams doing different data types).
If there are more natural scientists than computer scientists, we'll look for projects that can be implemented with ParaView or VisTrails by combining multiple modules and setting their parameters, rather than by coding in C/C++ or VTK (the degree-of-difficulty score will be artificially inflated). In this case, two natural scientists will work on the project, one primarily responsible for visualization code development and the other primarily responsible for goals and evaluation.
If there are more computer scientists than natural scientists, we'll find additional projects where CS students act as visualization generators for external clients, without a natural-scientist partner. In this case, two computer scientists will work on the project, one primarily responsible for visualization code development and the other primarily responsible for goals and evaluation.