Chapter 4 

One-Dimensional Graphics 

M. Firebaugh 

© Wm. C. Brown Communications, Inc. 

...of all methods for analyzing and communicating statistical information, well-designed data graphics are usually the simplest and at the same time the most powerful..
Edward Tufte

The first section of this book presented the technological basis for computer graphics visualization. In our definition of computer graphics as the creation and manipulation of graphical objects, the source of graphical objects is not specified. The most general definition of computer graphics encompasses the whole field of image processing, including images originating from video sources, digital scanners, and image libraries. A more restrictive view of computer graphics-one adopted by most textbook authors-defines graphical objects exclusively in terms of those generated algorithmically. In fact, classification of graphical objects as natural vs. artificial objects makes a fairly clean distinction between these two types.

Natural objects are those transferred into the machine from some external source. Some of the most common examples include: weather satellite photos, images from medical tomography, video, and scanner input. Artificial objects are those springing from the mind of the user and need not have any physical realization. Images created by painting, drafting, drawing, CAD, and all other generative programs fall into this category. As in all classification schemes, there are ambiguous and borderline cases. What is a scanned image of a computer generated blueprint? Is a perfectly rendered industrial part with all the dimensions and properties of the real part (and indistinguishable from a photograph), natural or artificial?

Whether we deal with natural or artificial objects, there are a host of object manipulation functions which we need in order to analyze and refine existing objects or create new ones. A few of these functions were demonstrated explicitly in Chapter 1, but many others were implicit in much of the other illustrative material presented to this point. For instance, the Drawing window object simply appears magically on the screen when the ShowDrawing command is issued in the algorithms of Chapter 3, but we have left it up to the student to carry out the operations of positioning the window conveniently (translation) and dragging the corner to size it appropriately (scaling). Both of these functions may be accomplished under program control but were omitted to simplify the programs. We will deal explicitly with window systems in the chapter on graphical user interface design.

So beneath the smooth facade of any program with a well-designed graphical user interface, there is a lot "going on." The casual user of such programs need not be aware of all the graphical algorithms and their mathematical basis. Students of computer graphics, however, will gain a much keener appreciation of the beauty of these programs and the skills required for building their own graphics applications through knowledge of the graphics fundamentals.

Because many fundamental graphics concepts are basically geometric, we take an N-dimensional approach in which N starts at one and increases throughout the section. For instance, the concept of translation is much simpler in one dimension than in two or three. Manipulations possible in 1D correspond to those from arithmetic-the operations possible on scalars. Moving into 2D and 3D we need to introduce vectors and vector operations, and new possibilities in rotation operations open up. This N-dimensional approach, with N = 1 Æ X, should be familiar since it parallels our experience of learning mathematics in elementary school.

Though an N-dimensional approach has the instructional advantage of corresponding to our mathematical development, it also introduces some interesting problems. Chief among these are the intriguing phenomena encountered in scaling from dimension one to higher dimensions. A popular discussion of these issues is given in the book Flatland. A more rigorous treatment is presented by Barnsley in Fractals Everywhere.

Translation and Scaling Transformations in 1D

What do we mean when we speak of objects in one dimension? Perhaps we should step back one dimension and discuss objects in 0D. In zero dimensional space, the only object is the primitive object, the point. A mathematical point is a dimensionless object. The nearest computer graphics analog to a mathematical point is the pixel. The analogy is a bit misleading, however, since unlike points, pixels do have a physical size (e.g., 1/72 inch) and other attributes such as color and brightness. Pixels also have another property, location, which is important to their status as computer graphical objects but completely non-essential to their status as mathematical objects. Their only status as mathematical objects is their existence or non-existence, and the only operators are the creation and annihilation operators.

Now consider what happens when we turn the dial on our dimension meter from 0 Æ 1. Three important phenomena are worthy of note.

  • The primitive object(s) present in dimension (N - 1) continue to exist.

  • New primitive object(s) of dimension N emerge, in this case, the line segment, hereafter referred to as the line.

  • A new set of transformations, undefined in dimension (N - 1), appear.

    Specifying Points and Lines

    The newly emergent 1D object, the line, has the mathematical property of length. As a measure of length, it helps to establish a 1D coordinate system as shown in Figure 4.1.
    Figure 4.1
    A 1D coordinate system.  

    The establishment of the 1D coordinate system provides two useful functions: a) length determination, and b) position specification. These operations are indicated graphically in Figure 4.2.
    Figure 4.2
    Using 1D coordinate systems for functions:
    a) Length: Line is 4 units long,
    b) Position: Points at 0.5, 1.75, line starts at 2.5 units. 

    Note that both the position of points and the length of lines are scalars (objects specified by a single number) in a 1D coordinate system. To completely specify a line, both its position and length must be given. Two conventions are possible:

        (X,L)                                    [4.1]
       X = left hand end point position
       L = length.
    or, alternatively,
         X1= left hand end point position
         X2= right hand end point position.
    Thus line (a) is specified by (0,4) in either convention, and line (b) is specified as (2.5,5.0) in the two-point convention.

    Note that the point-length and two-point conventions are equivalent in their information content. Each is easily derivable from the other:

        X1= X
        X2= X + L                                 [4.3]

    Translating Points and Lines

    Perhaps the most widely used transformation in computer graphics is that of translation-moving graphical objects around the screen. In 1D, translation is restricted to sliding objects along the X axis. Translating an object at point X a distance T moves the object to point . The equation relating these quantities is:

        X´ = X + T                                [4.4]
    Because the length of a line remains unchanged under translation, we can specify the translation of a line as:
        (X,L) Æ (X´,L) = (X + T,L)                [4.5]
        (X1,X2) Æ (X1´,X2´)= (X1 +T, X2 +T)       [4.6]
    Applying several translation operations to the objects shown in Figure 4.2 produces the configurations shown in Figure 4.3.
    Figure 4.3
    Translations applied to objects of Figure 4.2.
    a) T = +1.5
    b) T1 = +3 (points)
    T2 = -2 (line).

    Note that both points and lines behave similarly under the translation operation. Also, conceptually, the translation,T, of a line may be considered the translation of the infinitely many points composing the line, each by the amount T. Computationally, it is much simpler to simply translate both end points and assume the intermediate points "ride along." Good OOP style suggests defining the line as an object and sending it the message "Move T."

    Scaling of Points and Lines

    Perhaps the next most important transformation in computer graphics is that of scaling. This operation frequently goes under the names of magnification/demagnification and zoom in/zoom out. Since points have zero dimension, there is nothing to magnify except their position. Therefore, the behavior of an individual point under scaling is indistinguishable from its behavior under translation.

    Figure 4.4
    Scaling operation with S = 2.5.
    a) Original line,
    b) Scaled line.


    Figure 4.5
    Scaling operation with S = 2 applied to line not including the origin.
    a) Original line,
    b) Scaled line.
    Note both magnification and shift of line. 

    The equation for scaling is a simple multiplication of each coordinate, X, by the scale factor, S. This operation transforms each point into a new location, X´.

        X´ = S X                              [4.7]
    This appears to be quite an intuitive idea, and our intuition is borne out in Figure 4.4 in which a line of length L = 2 starting at the origin grows to length = 5 when scaled by a factor of S = 2.5. Scaling of a line involves scaling the two end points, connecting the scaled end points with a line, and interpreting this line as the collection of scaled points connecting the end points.

    An interesting phenomena appears when scaling is performed on objects located away from the origin. In Figure 4.5 we show what happens when we scale an L = 2 line located one unit from the origin with a scale factor S = 2.

    Scaling of an Object about a Point

    Note that the scaling operation performed on objects not located at the origin result in both a magnification by the scale factor and a translation. The translation may or may not be a desired side effect of the scaling operation. In many instances, the objective of scaling is simply to magnify the object "in place." This is called scaling of an object about a point. This objective may be achieved by the introduction of a new concept-a sequence of operations. Suppose, for instance, that the goal is to magnify the line shown in Figure 4.5(a) while keeping its center located at location 2.0. This is easily accomplished by the following three-operation sequence of transformations:

    1. Translate the line by T = -2 to move its center point to the origin,

    2. Scale the line by S = 2,

    3. Translate the line back using T = +2 to return its origin to location 2.

    The results of this sequence of operations are shown schematically in Figure 4.6.

    Figure 4.6
    Scaling of an object about a point at location 2:
    a) The original line
    b) Translated by T = -2
    c) Scaled by S = 2
    d) Translated by T = +2. 


    Reflection Transformation

    A final transformation of great utility in graphics synthesis programs is that of reflection. We are all familiar with reflection from our daily experience with mirrors. The 1D representation of reflection is given simply by the scaling operation with S = -1. That is, each point on an object with coordinate X maps into coordinate X´ = -X as shown in Figure 4.7.

    Figure 4.7
    Reflection transformation given by S = - 1. Note that X´ = - X.  

    Two observations may be helpful in better understanding reflections. A quick glance at Figure 4.7 might suggest that the transformation of the line (X2,X3) into line (X2´, X3´) could equally well be accomplished by the translation, T = -7. This is clearly not the case, however, as a check on the mapping of X2 proves. A translation of T = -7 would map X2 onto X3´ rather than X2´ as it ought. So the reflection operation involves primarily an inversion of all objects as well as a translation of objects not centered at the origin.

    The second observation is that the operation of reflection about a point may be accomplished by a sequence of operations just as the scaling about a point was. The three-step sequence for reflection about a point at location P includes:

    1. Translate the object by T = -P

    2. Scale the resulting object by S = -1

    3. Translate the resulting object by T = +P.

    Figure 4.8 shows that these three steps do, indeed, reflect the original object by a mirror at point P.

    Homogeneous Coordinates and Transformations

    The reader may have noticed that scaling and translation are fundamentally different kinds of transformations. One is multiplicative, and one is additive. As we turn the dimension dial up to N ≥ 2, we shall encounter additional multiplicative transformations for performing rotations and perspective transformations. It would be highly desirable to devise a mathematical formalism capable of representing all of these transformations in a coherent and systematic manner. Early computer graphics researchers recognized the need for such a uniform representation and proposed a system we call the homogeneous matrix representation.

    Figure 4.8
    Reflection about a point, P. The reflection through a mirror at location P (original configuration (a) is performed by the sequence: (b) translation by T = -P, (c) scaling by S = -1, followed by (d) translation by T = +P. Note that reflection (b) Æ (c) really does invert the scene.  


    The fundamental idea of a homogeneous coordinate system is that for representing points in an N-dimensional system, we use an N+1 dimensional representation. Thus, the scalar representation of a point (X) is represented in a homogeneous system as the vector, (x,w). Since w is simply an arbitrary over-all scale factor, the customary definition is w = 1. This results in the relationship:

        (X)  Æ (wX,w)  Æ (x,w)                 [4.8]
    where (x,w) are the homogeneous coordinates of the point X.

    Normalizing the homogeneous coordinates by dividing by w gives:

       (x/w,w/w)  Æ (x/w,1)  Æ (x,1)            [4.9]
    after applying the convention that w = 1.

    Note that the relationship between the conventional coordinate X and the homogeneous coordinate, x, is given by

        X = x/w                                 [4.10]
    where w is arbitrary (but not 0).

    Therefore, the 1D point X = 4 may be represented by the equivalent homogeneous coordinate pairs (x,w) = (4,1), (8,2), or (20,5). This redundancy can be eliminated by selecting the convention, w = 1, for which X = x. Blinn has pointed out that this convention is equivalent to the projection of the (x,w) 2D point onto the w = 1 line along a line from the point through the origin. This geometric interpretation is shown in Figure 4.9.

    Figure 4.9
    Geometric interpretation of transformation of homogeneous coordinates, (x,w), into conventional coordinate, X. The X coordinate is the intersection of the ray from the origin to the (x,w) point with the w = 1 line. Note that all equivalent homogeneous coordinate pairs such as (1.67,1), (2.5,1.5), (5,3), etc. would all project to x = X = 1.67 by this projective technique.  


    Matrix Formalism for Transformations

    Note that the combination of the scaling and translation transformation may be written as:

        X´= S X + T                           [4.11]
    The combination of such transformations, that is, a linear scaling followed by a translation, is called an affine transformation. One property of affine transformations is that the operators performing the transformation must be one dimension larger in rank than the dimensionality of the objects on which they operate. To perform affine transformations on our 1D objects, we shall need 2D operators, that is, matrices of rank 2. When we transform 2D objects, we will use 3D operators. Barnsley discusses the properties of affine transformations in more rigorous detail.

    Matrix Conventions

    The general formalism for operating on object X with operator O to transform it into object X' is given as:

        X´ = O X                                [4.12]
    The objects in this case are two, three, and four dimensional vectors representing points in 1D, 2D, and 3D space, and the operators are 2 ¥ 2, 3 ¥ 3, and 4 ¥ 4 matrices. The conformality requirement for matrix multiplication in Equation 4.12 requires that X be a column vector. This is the standard convention for matrix operations in physics, mathematics, and engineering. For reasons lost in the historical mist, but possibly related to the ease of writing row vectors compared to column vectors, the computer graphics community has generally chosen to work with row vectors rather than column vectors. Thus, the computer graphics convention requires reformulating equation 4.11 as:
        X´ = X O                                [4.13]

    Matrix Representation of Affine Transformations

    With this background in matrix conventions and homogeneous coordinates, the affine transformation representing an arbitrary scaling by S and translation by T may be written:

        X´= X·M                               [4.14]
       X'= [x' 1]      (2 ¥1 row vector),

       X = [x 1]       (2 ¥ 1 row vector),


       M =    (2 ¥ 2 matrix).

    Note the boldface convention: vectors and matrices (i.e., objects with internal elements) are written in boldface. To verify that Equation 4.14 is, in fact, equivalent to Equation 4.11, we can multiply the vector X  by matrix M to get:
        [x´1]  =  [x 1]                       [4.15]
    Doing the matrix multiplication (remember the two-finger, row/column rule?) gives:
        x´  =  x S + T                            [4.16]
         1 = 1
    The first equation in 4.16 agrees with 4.11 when we substitute the identity X = x, and the second equation is a trivial solution corresponding to the redundant nature of the homogeneous representation.

    Several points are worth noting about this matrix formalism. First is that the affine transformation given by Equation 4.11 may be decomposed into its constituent transformations, scaling and translation, within the formalism. Thus, the scaling transformation may be written:

        X´=X·S                              [4.17]
    and the translation transformation as:
        X´= X ·T                             [4.18]
        S  =    and T           [4.19]
    Secondly, complex transformations, such as the reflection through a point described in Figure 4.8, may be performed by a single matrix, M, which is the composed transformation obtained by multiplying together the matrices of the individual transformations. For instance, in Figure 4.8, consider the three transformations:
    1. Translation by T1 = -2,

    2. Scaling by S = -1,

    3. Translation by T2 = +2.

    The concatenated matrix, M, is simply
        MT1·S·T2                           [4.20]

    Interpreting this result as the affine transformation, X´= S X + T, we see that the mirror reflection about point P = 2 is accomplished by the combination of scaling by S = -1 followed by a translation of T = + 4.

    Finally, consider the power and elegance of the matrix formalism on homogeneous coordinates. The transformation matrix, M, given in Equation 4.20 is just a taste of things to come. When we derive the transformation matrix for rotation about an arbitrary axis in 3D, we must perform SEVEN distinct transformations. By concatenating the seven transformation matrices into a single matrix, we achieve tremendous computational efficiency. Since all transformations of interest in computer graphics may be expressed as a single transformation matrix, M, the formalism provides a simplicity and elegance of great value in generating program code. So rather than writing a separate matrix multiply routine for scaling, translation, rotation, perspective, and viewing, a single routine will solve all transformations.

    One last observation is in order on the pedagogical rationale for introducing rather abstract concepts such as homogeneous coordinates and matrix algebra for solving the almost trivial transformations allowed in 1D. Isn't this really killing a gnat with a sledgehammer? If we were to stop at 1D graphics, the answer is certainly "yes." However, the formal mathematics from this section will transfer smoothly to our studies of 2D and 3D transformations. Illustrating the concepts using 2 ¥ 2 matrices from 1D is four times more efficient than using the 4 ¥ 4 matrices of 3D. Not only do the equations appear simpler (because, numerically, they are), but we also save typing and paper. This is one of the main reasons we have chosen an N-Dimensional approach and started with N = 1.

    ···   - - -   ···   · - - -   - - -   - · - -     - - -   ·· - ·     · - ·   · -   - · - ·   ··   - ·   ·

    Windows, Viewports, and Clipping in 1D

    Since 1D examples have proven useful to illustrate the concept of transformations, letís see what they can tell us about the concepts of windows, viewports, and clipping. Until now, we have dealt only with fairly abstract concepts of mathematical transformations which are completely independent of any real graphical display system. However, the viewing transformation concepts of windows, viewports, and clipping involve the process by which the image of real-world objects are projected on a real-world screen. Therefore, we must become more specific.

    First, what do we mean by a real-world 1D object? And what would a 1D, real-world screen look like? One 1D object of interest (actually, there are not too many) would be a graph of a Morse code message. One such message that hopefully will never be sent is shown above. When translated, this means SOS JOY OF RACINE, the international signal indicating the authorís boat is in distress. In International Morse code, the space between parts of the same letter is equal to one dot, the space between two letters is three dots, the space between two words is five dots, and a dash is equal to three dots. 

    Viewing Transformation Nomenclature

    The 1D "screen" for displaying such a message might consist of a linear row of LEDs or LCDs similar to the "peak detector" indicators on most audio tape decks. An interesting problem is: How many picture elements (pixels) would be required to display this image clearly on the 1D screen? Now that we can visualize what a 1D object might look like and the type of screen we might display it on, we can better understand the viewing transformation, the process by which we map the object into an image on the screen. Before defining the viewing transformation, however, it is necessary to define some terms which will be used frequently throughout the book.

  • Scene - The collection of real-world objects we wish to visualize. The first step in displaying the scene is to represent it in terms of numbers corresponding to the size, shape, and locations of the objects in the scene. This process is called building a model of the scene and involves issues of representation. It is accomplished by building a numerical database, computing the numbers algorithmically, or capturing video or scanned images in image files.

  • Object space - The space in which the original object exists. The 1D object space of Morse code is the space of dots and dashes. The 2D object space of an integrated circuit chip design consists of the arrangement of component gates and connecting leads. The 3D object space of a motor consists of the physical arrangement of its components. Note that object space is completely independent of computers, screens, and how we look at the objects.

  • World coordinates - The coordinates for specifying the positions and shapes of objects in object space. The coordinates are given in natural units of the object space. In our 1D example the natural unit of the world coordinates would be one dot. The world coordinate units of a 2D IC chip would be in microns or thousandths of an inch. The natural units for specifying the 3D arrangement of components of a motor would be inches or centimeters.

  • Image space - The image space is the screen on which an image of the object is to be projected. The natural unit for describing image space on raster scan devices is the pixel. On our 1D display, pixels would be labeled from 0 to 255, for example. The image space of 2D displays such as VGA screens is a 640 ¥ 480 pixel array. At present, we have no 3D image display devices, but the goal of research on holographic techniques is to project 3D objects into 3D image space.

  • Normalized device coordinates - These are coordinates on the range 0 Æ 1 designed to eliminate the device dependence of screen coordinates. Thus, a NDC = 0.5 would refer to pixel 127 of our linear 0 - 255 pixel display. Most images in computer graphics are specified in terms of NDC. In actual practice, drivers must be written for each device to convert NDC into pixel coordinates of the screen.

  • Window - That portion of the scene selected for observation, specified in terms of world coordinates. In our 1D example the window would be specified by the two numbers, WL and WR, the left-most and right-most dot spaces we wish to display. Rectangular windows on 2D scenes are specified by the four world coordinates, WXL', WXR', WYT', and WYB', appropriate to the scene (e. g., centimeters, feet, or miles).

  • Viewport - That portion of the display device selected to show the image, specified in terms of NDC. On our linear display, the viewport would be specified by VL and VR, the left-hand and right-hand edges of the viewport. A typical, rectangular viewport on a 2D screen is specified by VXL', VXR', VYT', and VYB'. Although the nomenclature seems a bit inconsistent, the "windows" of windows operating systems such as Microsoft Windows, X Windows, and the Macintosh OS are really viewports by computer graphics definition and usage.

  • Viewing transformation - The operations required to map world coordinates of the model of a scene contained within a window onto the image space viewport. Three transformations required to perform the viewing transformation include:
    1. Translating one corner of the window to the origin in world coordinates.
    2. Scaling the window to conform to (fit) the viewport.
    3. Translating the scaled image to the desired viewport location.
  • Clipping - It is clearly unnecessary to apply the viewing transformation to those portions of the scene which lie outside of the window. The process of discarding any unwanted information is called clipping. From efficiency considerations, clipping should be applied in object space rather than image space. This is particularly important for high-magnification viewing transformations, that is, when viewing a complex scene with a very small window.

    The Morse code Example - 1D

    Now let us use the Morse code example to illustrate as many of these concepts as we can. The scene, in this case, is the collection of dots and dashes making up the message, SOS JOY OF RACINE. The object space unit is the dot, in terms of which the dash, character separation, and word separation are defined. World coordinates are specified in terms of the count of dot spaces, with the origin starting at the first dot or dash of the message. Image space consists of the row of LCD pixels on which we will map the image. The normalized device coordinates, XN, are real numbers on the range 0 - 1 and are obtained from pixel number coordinate, X, by the operation:

        XN = X/N                                 [4.21]

    where N = Number of pixels in display.

    Suppose, as the boat is filling with water, we wish to examine only the essential portion of the message, SOS JOY. We apply the window, (WL, WR) = (1,75), to bracket this submessage as shown in Figure 4.10.

    ···   - - -   ···   · - - -   - - -   - · - -      - - -   ·· - ·     · - ·   · -   - · - ·   ··   - ·   ·

    Figure 4.10
    Morse code "image" with linear window bracketing SOS JOY. 


    To make the mapping as simple as possible, we select a viewport as the leftmost 75 LEDs of the linear display. Assuming the display has 100 LED pixels, this corresponds to (VL,VR) = (0,0.75) in NDC. This selection provides a one-to-one mapping of the dot structure of the message to the LED pixels. In terms of the viewing transformation, this can be stated as a window translation of zero, followed by a scale factor of 1, followed by a viewport translation of zero. Clipping is done on the original scene by the simple test:

      if X > 0 and X £75

      then PLOT

      else SKIP.

    Applying this viewing transformation with clipping produces the image shown in Figure 4.11. 

    Figure 4.11
    Image of Morse code segment, SOS JOY, displayed on LED indicator.  


    Suppose we are now up to our neck in water and want to display a large SOS in the center of the indicator screen until the last gurgle is heard. We narrow our window down to (WL,WR) = (1,27) to bracket just the SOS, set the scale factor S = 2, and set the viewport translation to T = 23. Since the scaled message is 54 dots long, its center is at dot 27. We want to move this dot to LED pixel 50 of the 100-pixel screen, requiring a translation of 23 dots (pixels). In terms of the viewport, since the image is 54 pixels in size and we want it centered on the screen, we need (VL,VR) = (0.23,0.77). The resulting magnified, centered SOS distress call is shown in Figure 4.12.

    Figure 4.12
    Image of (1,27) dot window transformed to (0.23,0.77) viewport.  


    The Viewing Transformation

    Since the viewing transformation is a sequence of translation and scaling transformations, it should be possible to represent it by a general affine transformation of the form:

        Xd = a Xw + b                         [4.22]


        Xd = display device coordinate,
        Xw = world coordinates.

    As indicated above, the viewing transformation consists of the translation, T1, of the left "corner" of the window to the origin, followed by a scaling, S, to map the window onto the viewport, followed by a translation, T2, to shift the scaled image to the correct viewport location. In terms of the specified parameters, WL, WR, VL, and VR, it is apparent that these three transformations are given by:

        T1 = -WL                                 [4.23]
        S =(VR-VL)/(WR-WL)                        [4.24]
        T2 = +VL.                                [4.25]

    In the matrix representation, the concatenated transformation, M, is given as:

        M = T1·S·T2                         [4.26]
            = .                     [4.27]

    Multiplying out Equation 4.27 gives:

        M = .                             [4.28]

    The homogeneous coordinate representation of the viewing transformation can be written:

        Xd = Xw M                                [4.29]


        Xd = [xd 1] and Xw = [xw 1]    (Row vectors)

    Substituting 4.28 into 4.29 and multiplying out yields:

        xd = S xw + (S T1+T2)                         [4.30]

    which is indeed of the form shown in 4.22. Expressing 4.30 in terms of the viewing transformation parameters given in 4.23 - 4.25, we get:

        xd = S (xw + T1) +T2
            = (VR-VL)/(WR-WL)(xw - WL+ VL.              [4.31]

    Equation 4.31 is the final result, the equation of the viewing transformation in 1D.

    Alternative 1D Coordinate Systems

    The objective of 1D coordinate systems is the unique representation of scalar information, i.e., numbers. A number of other coordinate systems and visualization techniques have been developed for displaying scalar information. These include angular and polar coordinates and volume visualization techniques. While scalars can be correctly displayed on the linear, 1D coordinate system discussed above, it is often more effective and convenient to use one of the alternate coordinate systems.

     Angular Coordinates

    One of the most common, nearly universal, instruments for measuring electrical and physical quantities electrically is the d'Arsonval galvanometer. In this instrument, an electric current creates a magnetic force on a spring-loaded, mechanical indicator needle. By careful design, the needle movement shows a nearly linear response to current over a wide range of angular deflection. Since many quantities of physical interest (e.g., speed, temperature, pressure, flow rates, and so on) are easily transduced into electrical signals, electrical galvanometers remain in widespread use and will continue to do so for the foreseeable future. They remain extremely effective instruments for conveying information on stability, noise, oscillations, and other signal properties which are difficult to convey through a digital voltmeter output.

    Because of the attractive features of d'Arsonval meters and widespread experience with them, designers of graphical user interfaces, graphical tool kits, and graphical instrument simulation programs frequently supply a "meter" object for displaying scalar information. The user specifies the variable for display on the meter and the full-scale reading. The meter then provides a continuous display of the variable of interest. Figure 4.13 shows one possible application for angular coordinates displayed on a simulated meter.

    Figure 4.13
    Analog meter for displaying scalar information. Here the needle indicates that the 1.2 Mb disk is about 3/4 full of data.  

    Since angular-measure "meters" display only single scalars, they are not capable of displaying a linear image such as the Morse code message. However, other 1D graphical concepts, such as object space, world coordinates, and image space carry over directly to angular coordinates. The window on world coordinates is typically (0,Xfs), where Xfs is the full scale calibrated meter reading. The viewport is specified in terms of the angular range, (0,qm), where qm is the maximum angular deflection. A given world coordinate, X, is mapped to the appropriate angular coordinate, q, by the transformation:

        q = S X                             [4.32]


      S = qm/Xfs       (scale factor).
    Figure 4.14
    Two examples of polar coordinate displays. In (a), the two hands indicate two angular points which we interpret as hours and minutes; in (b), the pie segments indicate angular intervals equivalent to line segments in 1D linear displays.  


    Polar Coordinates

    The limitations of the angular meter capable of displaying only angular points can be overcome by using more generalized polar coordinates. Polar coordinates can represent both angular points (as the angular meter did) and angular intervals (the angular equivalent of a line with length). In Figure 4.14, two examples of 1D polar coordinate representations are shown.

    It is important to take note of certain constraints imposed by 1D polar coordinates. First is that the "viewport" in almost all cases corresponds to q on the range 0°-360°. This is not necessarily always the case, however. Consider the polar coordinate indicator shown in Figure 4.14(a) which we all recognize as a clock. Although probably the most commonly used measuring indicator, the reading and correct interpretation of clock information is a non-trivial task. The difficulties of mapping the scalar called time of a 24-hour day onto a clock face can be summarized as:

  • There is a two-fold redundancy in a given reading, a.m. and p.m., which can only be resolved by "keeping track of time" or looking out the window.

  • The indicator system is a hybrid digital-analog system. The small hand indicates the hour digitally. The large hand gives an analog minute reading unless there is a second hand, in which case the minute hand becomes digital and the second hand is analog.

  • A clock face generally provides two superimposed polar coordinate scales, neither of which is labeled, with the hour scale numbered and the minute scale simply marked by tick marks. Full rotation of one hand corresponds to 12 units and that of the other, 60 units.

  • One complete "clock cycle" of the small hand is two complete revolutions or 720°. That of the large hand is 24 revolutions or 8,640°. Thus, the "viewport" may be considered as 2 layers or 24 layers of a 360° basis.

    These complexities explain why reading time is one of the major subjects of the first few years of primary education.

    Perhaps the most common usage of polar coordinates in graphics is the so-called "pie chart" shown in Figure 4.14(b). Pie charts are generally used to display the relative sizes of the components of some whole object, in this case, the Midwest Sales of a fictitious company by state. If the size of the whole object is represented by the window, Xt, and each component of the window is Xi, then the appropriate size of each angular pie, qi, is given by:

        qi = S Xi                             [4.33]


      S = 360/Xt       (scale factor).

    Volume Visualization

    A final 1D application, widely used and often abused, is the representation of scalar quantities as volumes. For example, to represent automobile exports by country, auto icons are used with sizes scaled to represent the volume of export. Analyses of natural resources frequently use volume visualization techniques with, for instance, the size of a coal pile representing coal production by state and the size of an oil barrel representing oil imports by country.

    Consider, for instance, using volume visualization to represent the data of Table 4.1 on estimated shale oil resources of the world.

    Table 4.1
    Shale Oil Resources of the World
    Total Estimated Resources (10 9 bbl)
    Australia/New Zealand
    North America
    South America

    The temptation in using volume visualization to represent these scalar numbers is to construct the barrel for Australia/New Zealand and simple scale it by two times to generate South America's resource, three times for North America, and so on, to produce the graph shown in Figure 4.15.

    In Figure 4.16, the correct representation of the volumes is presented, with a scaling of the linear dimension by the cube root of the raw data. Thus, the Asian barrel in Figure 4.16 would hold 5.5 times as much oil as the Australian/New Zealand barrel-as it ought-rather than 166 times as much which the misleading Figure 4.15 would suggest.

    Volume visualization, correctly used, can be an effective presentation technique. Care must be taken, however, not to map scalars to the display screen with a linear mapping if the image icons represent areas or volumes. If the original scalars are interpreted as volumes, Vi, then the mapping of the linear dimension, Xi´, of the display icon should scale as:

        Xi´ µ .                             [4.34]

    Some authors caution against using 2D and 3D techniques for displaying 1D data because of the difficulty of design and the ambiguity in perception.

    Figure 4.15
    Misleading volume visualization of data from Table 4.1. Here the linear dimensions have been scaled by the numbers shown which results in a gross misrepresentation of the data.  


    Figure 4.16
    Correctly scaled volume representation of Table 4.1 data. The linear dimensions have been scaled by the cube root of the data. Note also the labeling of the graph which enables the reader to make use of the data.  

    Presentation Graphics in 1D

    The graphical mode for communicating numerical and conceptual information has become so pervasive that it has achieved its own designation, presentation graphics. Presentation graphics, using the media of overhead transparencies, slides, computer-generated video, or live computer output, has become the standard mode for reporting company earnings, market trends, organizational structure, and even presenting difficult concepts such as goals and strategy. A large share of presentation graphics efforts deal with effective techniques for representing and presenting 1D information.

    We have already been introduced to two of the most important modes for scalar data display. These two modes include:

  • Bar charts - a special case of the general 1D linear LED indicator,

  • Pie charts - several variations on the polar coordinate theme.
  • The user has two options for generating high-quality presentation graphics-commercial programs or homegrown programs. Because of their generality, power, and convenience, commercial presentation graphics programs will in most cases be the preferred option. However, we shall demonstrate both options in order to give the reader a better feeling for the techniques and programming effort incorporated in commercial programs and problems the programmer must resolve.

    Presentation Graphics Techniques

    For converting scalar information efficiently into convincing bar and pie charts, graphical spreadsheets such as Lotus 123™, Quatro Pro™, Excel™, and WingZ™ are hard to beat. Consider the following steps for displaying data from Table 4.1.

    1. Open WingZ by a single menu select.

    2. With the mouse, select the ten items from the table in the word processed text by sweeping from "Africa" to "2000," and select Copy from the Edit menu.

    3. In the WingZ screen select a conformal region of the spread sheet (5 rows ¥ 2 columns), and select Paste from the Edit window.

    4. Click on the "graph" icon, and drag a box on the screen for the graph.

    Figure 4.17
    Bar chart of Table 4.1 data copied into and displayed by WingZ.


    Figure 4.18
    Reformatted and labeled bar chart of Table 4.1 data. 

    These seven mouse operations, which require about 20 seconds, generate the graph shown in Figure 14.17. Note that this shaded bar chart has been produced without typing a single key.

    Next, we restructure and label the bar chart of Figure 4.17 to produce Figure 4.18. The changes made include:

    1. Type a Title ("Shale Oil Resources") and Legend ("Trillion bbls") at the top of the two data columns and change fonts and sizes to those shown.

    2. Position the Title and Legend at the top of the graph by menu selection under Graph/Title and Graph/Legend.

    3. Select Vertical Parsing under Graph/General to label the x-axis.

    Note that this reformatted graph did, in fact, require typing the Title and Legend and shortening up the "Australia/New Zealand" name. This typing, plus five selections with the mouse, reformatted Figure 4.17 into Figure 4.18.

    The stacked format provides a final variation of bar chart. Making two mouse selections from the Graph/General menu, Vertical Stacking and Horizontal Parsing, converts Figure 4.18 Æ Figure 4.19.


    Figure 4.19
    Vertically stacked shaded bar chart of Table 4.1 data.  

    A single mouse select of Pie from the Graph/Gallery menu converts this into Figure 4.20.

    And, finally, the visually appealing but somewhat overworked 3D pie chart of Figure 4.21 is obtained by selecting this format under Graph/Gallery. The only other change made was to turn off the Automatic Layout feature under the Graph/General menu in order to manipulate the title and legend. These were dragged into their final position in order to compress the figure and save space.

    Figure 4.20
    Pie chart of Table 4.1 by WingZ. 


    The purpose of Figures 4.17 - 4.21 is to demonstrate the ease and versatility with which modern, graphical spreadsheets can be used to produce presentation graphics of scalar data in the form of 1D bar charts or pie charts. The user need only key in or copy data into the spreadsheet, open a viewport on the spreadsheet, and the graph magically appears. With a few more mouse clicks, the user can rearrange the display into any desired format.

    A final advantage of the graphics produced by programs such as WingZ is their object-oriented structure. That is, the 3D pie shown in Figure 4.21 is really composed of individual graphical elements which may be grouped and manipulated by any drawing program. So, for instance, Figure 4.21 may be copied into Canvas and partially "exploded" as shown in Figure 4.22 by selecting and dragging the component pie slices into any desired location. The OOP nature of the elements of the graphical pie object supports messages such as "select yourself," "join a group," "move to this location," and "go to front" or "go to back" layers. Such object-oriented features provide graphics designers with maximum flexibility.

    Figure 4.21
    3D Pie Chart of Table 4.1 data.  


    Figure 4.22
    Results of manipulating the graphical elements of the pie object of Figure 4.21. By copying the image of Figure 4.21 into a drawing program, the graphics designer has complete freedom to manipulate the component elements as desired.  


    Bar Charts in Pascal

    To help readers understand and appreciate some of the algorithms employed in commercial graphics programs, it is useful to write a program to implement one of the simpler graphical functions of WingZ. The design criteria for the Pascal program, BarCH, will be to provide modest capability with minimal programming effort.

    To be more specific, let's design BarCH with the following features:

  • The user can select an existing data file to plot or choose to enter data from the keyboard.

  • The format for data entry will be an arbitrary series of (Xi, IDi) pairs, where Xi is the numerical value of the scalar to be plotted and IDi is the identifier.

  • The program will count the number of data entries and scale the axes automatically to accommodate the data.

  • The user will be queried for the graph title and labels for two axes.

    Pascal Program BarCH 

    program BarCH; {Program to automatically plot BAR CHART based on }
    {user supplied graph title, axes labels, and data. }
    {Data may be supplied as existing file or keyed in } {directly. }


    left = 50;
    right = 450;
    top = 40;
    bottom = 340;
    XaxisB = 50;
    XaxisE = 350;
    YaxisB = 255;
    YaxisE = 5;
    Title, OrdLab, AbsLab: string;
    DataFile: text;
    ID, OutLine: string;
    npoints, ScMax, ScMin, tens, Dy: integer;
    Max, Min, x: real;
    Sy, Dx: real;
    procedure GetInformation;
    {Routine to open interactive query viewport to input }
    {essential information. }
    TextPort: rect;
    i: integer;
    ans: string;
    begin {Set up text window and open it.}
    SetRect(TextPort, left, top, right, bottom);
    WriteLn(' Bar Chart Grapher');
    Writeln('How shall we title this graph? (enter string)');
    Writeln('Ordinate Label? (enter string)');
    WriteLn('Abscissa Label? (enter string)');
    Writeln('Is data in table (T) or from keyboard (K)? Enter T or K');
    {If data file exists, query for its name.}
    if (ans = 't') or (ans = 'T') then
    {Use file query function, "OldFileName"}
    Reset(DataFile, OldFileName('DataFile for Bar Chart?'))
    else {Otherwise, create it from the keyboard.}
    ReWrite(DataFile, 'BarCH.dat'); {Open for writing.}
    Writeln('Please key in data in format (Xi _ IDi) <cr>');
    Writeln('Terminate with message (n _ end) <cr>');
    Writeln(' where _ = space, n = number, "end" = sentinal to stop');
    Readln(x, ID);
    repeat {Read and write data points until end.}
    Writeln(DataFile, x, ID);
    Readln(x, ID);
    until ID = ' end';

    procedure Normalize;
    {Routine to scan data to count points and set Min and Max.}
    {Round to nearest single digit inclusive number and}
    {extract power of ten for correct scaling.}

    i, n, b: integer;
    a: real;  
    function sign (z: real): real;
    {Returns the sign as a real number.}
    sign := z / abs(z)

    procedure Reduce (xin: real; var a: real; var b: integer);
    {Procedure to read a real x and return it in the form a x 10**b}

    x: real;
    x := abs(xin);
    if x < 1e-10 then {Test if number Å o; set a,b =0}
    a := 0.0;
    b := 0;
    else if x < 1 then {Scale small numbers up by powers of 10}
    b := 0;
    x := 10 * x;
    b := b - 1;
    until x > 1;
    else {Case: x>1} {Scale large numbers down by powers of 10}
    b := -1;
    x := x / 10;
    b := b + 1;
    until x < 1
    a := sign(xin) * exp(ln(abs(xin)) - b * ln(10))
    end; {End Reduce}
    reset(DataFile); {Reset data file and open it for reading.}
    Max := -1e30;
    Min := -Max;
    npoints := 0;
    Readln(DataFile, x, ID);
    npoints := npoints + 1;
    if x > Max then
    Max := x;
    if x < Min then
    Min := x;
    until eof(DataFile);
    Reduce(Max, a, b); {Convert Max to power of 10 notation.}
    ScMax := Trunc(a + 1); {Round single digit up.}
    Tens := b;
    Reduce(Min, a, b); {Convert Max to power of 10 notation.}
    if b < Tens then
    ScMin := 0
    ScMin := Trunc(a - 1);{Round single digit down.}
    end; {End Normalize}

    procedure PlotAxes;
    {Routine to plot and label abscissa & ordinate axes.}
    ViewPort: rect;
    i, n: integer;


    {Open Drawing window as viewport.}
    SetRect(ViewPort, left, top, right, bottom);
    {Draw Ordinate axis (Y), with arrowhead.}
    DrawLine(XaxisB, YaxisB, XaxisB, YaxisE);
    Line(5, 10);
    Line(-10, 0);
    Line(5, -10);
    {Draw Abscissa axis.}
    DrawLine(XaxisB, YaxisB, XaxisE, YaxisB);
    {Compute Dx, width of bar.}
    Dx := (XaxisE - XaxisB) / (2 * Npoints);
    {Compute Sy, the ordinate scale factor.}
    Sy := (YaxisB - YaxisE) / (ScMax - ScMin);
    if tens > 0 then {Scale by appropriate
    power of 10}
    for i := 1 to tens do
    Sy := Sy / 10
    else if tens < 0 then
    for i := tens to -1 do
    Sy := 10 * Sy;
    Dy := Round((YaxisB - YaxisE) / (ScMax - ScMin));
    n := 0;
    {Draw tick marks and label ordinate axis.}
    for i := ScMin to (ScMax - 1) do
    MoveTo(XaxisB - 15, YaxisB - n * Dy + 4);
    WriteDraw(i : 1);
    MoveTo(XaxisB, YaxisB - n * Dy);
    Line(5, 0);
    n := n + 1;
    MoveTo(XaxisB + 50, YaxisE + 10);{Write Title}
    MoveTo(XaxisB + 150, YaxisB + 25); {Label abscissa}
    {Label ordinate}
    MoveTo(XaxisB - 45, (YaxisB + YaxisE) div 2);
    {Write scale factor}
    MoveTo(XaxisB - 48, (YaxisB + YaxisE) div 2 + 15);
    Move(3, -5);
    WriteDraw(Tens : 1);
    Move(0, 5);
    end; {End PlotAxes}

    procedure PlotData;
    {Routine to plot data bars.}

    i, L, R, T, B: integer;
    Bar: rect;
    B := YaxisB;
    for i := 1 to Npoints do
    begin {Read point and build Bar rectangle}
    Readln(DataFile, x, ID);
    T := B - Round(Sy * x) + Dy * ScMin;
    L := XaxisB + Round((2 * i - 1) * Dx);
    R := XaxisB + Round((2 * i) * Dx);
    SetRect(Bar, L, T, R, B);
    PaintRect(Bar);{Plot bar by painting rectangle}
    MoveTo(L, B + 12);{Label each bar with its ID}
    end; {End PlotData}

    begin {Main program}



    Program Operation

    The overall structure of the program is indicated by the mnemonics of the four worker routines called by the main program. Rather than passing variables through the argument lists of procedures (the generally preferred style), the simpler option of making most variables global for processing by worker routines was selected. The only two items which may appear mysterious are:

  • The use of OldFileName - This routine opens a query window labeled by the prompt supplied as its argument and allows the user to scan through volumes and scroll through file names to select and open the file of their choice. It is an operating system routine which provides the application programmer an efficient shortcut to this repetitive task.

  • The scaling performed by Normalize - The task of mapping the window (range of Xi data values) to the viewport (250 pixels along the y-axis) is essentially trivial. The problem with this straightforward scaling is that the y-axis scale readings will range from Xmin = 2385 to Xmax = 7592, for example, in five evenly spaced but odd-ball numbers spanning the range. The purpose of Normalize is to map the window onto a slightly demagnified window that has edges are WL = 2 ¥ 103 and WR = 8 ¥ 103. The algorithm is designed to round the most significant figure of Xmin downward and the most significant figure of Xmax upward and extract the power of ten for graph labeling purposes. Only the most significant figure is used to label the y-axis intervals. This algorithm generally works well, failing only in cases such as Figure 4.24 in which Xi data values vary only in the second significant figure.

    Figure 4.23
    Output of BarCH operating on Table 4.1 data. 


    Program Features and Output

    Let us see how BarCH handles the data of Table 4.1. Figure 4.23 shows the results of selecting the properly formatted data file, BarCH.Oil.

    Although BarCH is not a model of elegant programming, the program does have certain attractive features. These include:

  • Flexibility in selecting data from existing file or direct interactive input.

  • Automatic scaling of data over all ranges of real number magnitude.

  • Capability of handling negative numbers. (What is a negative bar chart?)

  • Rounding to give simple 1 digit coordinates on y-axis.

  • Automatic offset of closely compacted data.

  • Arbitrary number of data points handled automatically without arrays.
  • Some of these features were fairly difficult to program, particularly with Pascalís poor support of mathematical functions such as log and x.y

    Even with these nice features, BarCH is extremely weak compared to the presentation graphics of programs such as WingZ and Excel. Some of these limitations become apparent in the final figure, Figure 4.24.

    The limitations of this program illustrate the problems inherent in building completely general graphics programs. These problems include:

  • Difficulty of accommodating arbitrary length titles and labels,

  • Limited amount of data before clutter becomes overwhelming.
  • Two other observations are appropriate at this point. First is that the orientation of the bars selected for BarCH is sometimes called a column graph rather than a bar chart. A horizontal bar chart has several intrinsic advantages over the column graph shown. The programming is simpler, and it is easier to label the bars both by ID and numerical value. A serious shortcoming of BarCH is the lack of numerical labels on each bar.

    Figure 4.24
    BarCH output on another data file.  



    Many of the basic concepts of higher-dimensional graphics are clearly illustrated by a careful study of 1D graphics. Graphical transformations of translation, scaling, reflection, and viewing have concise and simple definitions in 1D that transfer smoothly into higher dimensions. The rationale for the matrix formalism and homogeneous coordinate systems can be made as convincingly in 1D and demonstrated more economically than in 2D or 3D. The definitions of windows, viewports, and clipping have precise 1D analogs which extend seamlessly to higher dimensions. The viewing transformation concepts are illustrated with the Morse code example. Scalar quantities may be represented by coordinate systems other than the linear Cartesian axis. For instance, scalar data is frequently displayed on meters (angular coordinates), pie charts (polar coordinates), and as volumetrically scaled icons. Finally, valuable tools for 1D presentation graphics were illustrated with bar charts and pie charts. The considerable programming effort involved in elegant presentation graphics programs is better appreciated by the contrast with results from a modest Pascal bar chart program.