A.5 Presentation: Issues and Techniques

Visualization is used to represent natural phenomena that are inherently visual themselves, but probably more often, it is used to "visualize" non-visual phenomena. The process of making something visual means making choices on the part of the program author or designer. Clearly, without a sound scientific basis for these choices, this can become a purely artistic venture. While computer graphics can be used to make beautiful artwork, that is presumably not the point of using visualization to help study, analyze, or understand data. This does not mean that you should forego good design in making your visualization scene understandable. Remember and use the "rules" of design mentioned above, including proper, legible annotation, reasonable choices for colors, and so on. These things are determined partly by the medium you are working in and partly by the rules of good layout and design.

But what color is a magnetic field? What color is hot? What color is high? How fast should molecules vibrate? How quickly should a metallic surface move as it changes phase? These decisions must be made by the program author. Probably the three most critical choices are color, scale, and speed.

In visualization, color is used precisely because it is not realistic. That is, to emphasize an area of interest, red is commonly used. Or, a strong contrast color can be used against a field of fairly neutral colors. However, there are some cultural color choices that you may find inappropriate to violate. For historical and to some degree natural reasons, we tend to make color gamuts that indicate red as the "highest" and blue the "lowest." Particularly with temperature, we can associate blue with "cool" or water/ice color, and red with "hot" or flame/sun color. To some degree, this gamut is related to the color of heated metal, but of course, the metal color does not pass through green at the midway point, and the color scale does not end at white like white-hot metal, so this too is only a loose analogy. But try inverting a color map of temperature to make red cool and blue hot and you will probably find you have to perform mental gymnastics to interpret it "correctly." If you are mapping altitude, however, red is not necessarily best associated with the "high" point: after all, the highest altitudes are snow-covered and lower altitude deserts are frequently "red-hot"! Actually, color-mapping altitude is almost purely an artistic endeavor, but at least it has a long history and literature in cartography. Consulting the "traditional" textbooks for a field may indicate how users in that discipline "prefer" things to be mapped. It is generally unwise to start a new schema for your visualization if you wish it to be immediately accessible to other viewers familiar with the discipline. But relating new ways of visualizing data to the old methods may be a good way to provide new insights for everyone involved.

Remember that to use interpolation, the basis of your assumptions is that the phenomenological space studied is continuous and linear. If you have reason to believe the sampling was not done over a domain that can be linearly interpolated, you should certainly not be using linear interpolated images to understand the data. You may need to collect more data on a finer grid to resolve such problems. Since Data Explorer supports irregular grids, this is not a problem for the software, as long as you provide the correct data sampling. Also, be aware that trying to read too much detail out of an image is an error. You cannot accurately assess detail at a resolution equal to or less than your sampling rate (the Nyquist law states that you cannot derive valid signal from noisy information at less than twice your sample rate). For example, occasionally, you will see peculiar color artifacts that arise when data and therefore interpolated colors change rapidly at the scale of the sampling mesh. In those cases, the best bet is to "zoom out" to see only the big picture: do not try to read between the lines!

Related to sampling rate in space is sampling in time. Be sure you have collected enough time step detail to ensure you have not completely missed some important transitional state that might have occurred in the middle of an animated sequence. It is acceptable to skip through the entire range of time steps during the development of your animation, but be sure to fill in the gaps before the final presentation is analyzed.

As in traditional statistical plotting, a computer can all too easily permit the author to scale objects or graphs into wildly distorted aspects. In charting, there are some simple rules of thumb: it is often suggested that the aspect ratio (height/width) be about 0.75 to 1.00 for a 2-dimensional chart. This may require rescaling one axis, and naturally, both axes and their scales must be shown. It is also bad form to start an axis at one point then create a break part way along, causing a visual foreshortening. And it is also inappropriate to start an axis at a point other than the origin if the intent of the chart is to represent absolute amounts of quantities being compared side by side. All of these rules of thumb are employed to make "good" charts; nevertheless, these rules are too often violated even in the mainstream media.

Unfortunately, these traditional rules of scale do not help us much when we create 3-dimensional objects of arbitrary shape. So it becomes incumbent upon you to make sensible decisions in depicting objects never before seen by any viewer. It will be very easy to exaggerate a 3-D height field by changing the scale factor in Rubbersheet. You can make the one high point in the data leap as high as Mt. Everest. If that point is in fact a special value in your data, this may be an appropriate thing to do. If not, you may wish to choose a scale better suited to depicting the entire surface. On the other hand, if there are peaks, you must avoid "crushing" the entire surface to lessen the high points. Doing so could lead to potential misinterpretation of your results.

For many researchers, Data Explorer will be the first program they have used that permits them to create and view animation or motion playback of their data. This new temporal dimension is often a source of problems until the author gets the hang of things. Here are a few tips as you develop your own "moving pictures."

First, remember that your viewers have never seen this phenomenon before. Give them a chance to absorb it: looping the entire sequence is usually helpful. You do not want to bore the viewer to death, but visualization is not a TV commercial: cutting to a new scene every two seconds is not a good editing technique for communicating difficult visual information. As we discussed in the section on Animation, showing the same sequence at more than one speed helps a viewer notice different information in the very same scene.

Visualization allows users (fortunately) to wildly distort time scales. One video may show the movement of tectonic plates, another the gyrations of atoms in a gas. One scale is millions of years, the other billionths of seconds, but both are brought into the "video" scale of one frame every thirtieth of a second. Clearly, you must use some kind of clock annotation, especially if you plan to change playback rates, and even more importantly, if you plan to show different data sets using the same type of animation. The user must be given a proper sense of how two animations compare in their duration if sense is to be made of these animated sequences.

However, humans are not particularly good at visual comparison from memory. We are good at pattern recognition and comparison, but we have inadequate temporal rate memories; we do not remember detail in relation to time because we do not have good time-keeping reference systems in our brain. That implies that you must either choose to show comparisons based on precisely the same time duration and playback rate (thus factoring out the time dimension), or, much better, show two motion sequences at the same time in the same picture. One way to accomplish this is to render two sets of images, then use the Arrange module to construct an animation showing the two sequences side by side. This technique is important if the two phenomena vary in a scientifically critical way during the process; for example, if one phase change event is virtually complete after 40% of the entire time step series and another phase change after 60%, this may represent one of the important findings of your research. But if you show the viewer first one sequence, then the other, very few people will be able to make a solid visual comparison from their memory. It is much more visually impressive to show the two phase change simulations side by side, starting at the same time, and proceeding for the same number of time steps.

Animation must also proceed quickly enough for the mind's eye to perceive it as animation. Imagine taking each time step of your simulation, making a 35mm slide, and loading up a slide carousel with ninety slides. A viewer who is shown each slide for 5 seconds is unlikely to perceive the "motion." Put on videotape, the same sequence of images takes only 3 seconds. This may be too fast: the entire event may flash by too fast for the viewer to see any change. You may need to double-record each image (i.e., slowing things down by one-half) making the video take 6 seconds. Another way (more computationally expensive) is to generate twice as many raw data files and twice as many images. This will yield smoother animation, but may be too costly for your resources. Of course, some events can be shown in 3 seconds: maybe everything stays the same for 1.5 seconds, then "pops" into a new configuration. Slowing this down too much might hide the importance of the sudden transition to a new state. Again, you, the user familiar with the field and with the phenomenon become a judge and a designer. You have to make wise decisions based on a desire to accurately and honestly depict the behavior under study with the purpose of illuminating other viewers, not impressing them with spectacular computer graphics displays.