/usr/share/doc/dx/help/dxall617 is in dx-doc 1:4.4.4-9.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 | #!F-adobe-helvetica-medium-r-normal--18*
#!N
#!CNavyBlue #!N #!Rall616 Presentation: Issues and Techniques #!N
#!EC #!N #!N 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. #!N #!N 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. #!N
#!N In visualization, color is used precisely because it is #!F-adobe-times-medium-i-normal--18*
not #!EF 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. #!N
#!N 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! #!N #!N 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. #!N #!N 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.
#!N #!N 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. #!N #!N 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." #!N #!N 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. #!N #!N 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. #!N
#!N 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. #!N #!N 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. #!N #!N #!N #!F-adobe-times-medium-i-normal--18* Next Topic
#!EF #!N #!N #!Limd,dxall618 h Importing Data: File Formats #!EL #!N #!F-adobe-times-medium-i-normal--18* #!N
|