Chapter 2 (Continued)

Output Devices

Since most readers are already familiar with several of the output devices listed in Figure 2.6 we will not discuss them individually. Instead, we now present a few observations on the technology and its economics.

First, all the output devices are available in both B/W and color. In general, one pays somewhere in the range of 50 percent to 300 percent premium in moving from B/W to color. However, the market is moving very rapid toward better color output devices at ever lower prices. As more color devices become available, the advantages of color as an aid to visualization are becoming more widely recognized. When color output becomes the norm, the pressure will build to produce low-cost effective copying devices, the lack of which is the last remaining obstacle to the widespread use of color.

The second observation is that a range of resolution is available on color devices, both in color resolution and spatial resolution. At the low end, one can add 144 dpi, 8-color capability to the ImageWriter II dot matrix printer for the cost of a 4-color ribbon (~$5.00). Color inkjet printers with 720-1440 dpi resolution in 16 M colors are available in the $200 - $400 range. Three hundred dpi thermal transfer printers cost $1K - $3K, and 6,000 dpi slide recorders are becoming available in the same price range.

Software/Firmware Systems

One logical way to analyze the software/firmware technology of computer graphics is to categorize it into the following classes.

System Software

GUI operating systems such as Microsoft Windows and the Macintosh OS provide a rich repertoire of functions for controlling the graphics interface and building application programs. Windows is a graphical extension to MS-DOS which provides an elegant graphical user interface to Windows compatible applications and a graphical shell for calling non-Windows applications. More importantly from the graphics programmer';s point of view is that Windows provides an object-oriented programming environment with access to graphical objects such as windows, icons, menus, and mouse events through high-level languages such as C, Turbo Pascal for Windows, and Visual Basic. Similarly, the Macintosh utilizes ROM firmware containing the operating system and the Macintosh User Interface Toolbox. Of particular interest to the graphics programmer are the Menu Manager, Window Manager, Control Manager, Event Manager, and QuickDraw routines.

Menu Manager give the programmer full control over the creation of menus, their contents, the "pull down" feature, and the highlighting of individual menu actions. Window Manager and Control Manager give the programmer the tools for creating windows with title bar, scroll bars, size box and close box, controls the selection and shuffling of overlapping windows, and tracks window pointers and WindowRecord data types. Event Manager builds event queues for recording events such as mouse button action, keyboard entry, and disk drive insertions, and properly integrates them with the Menu Manager, Window Manager, and operating system.

Programming Languages

Numerous dialects of all major high-level programming languages are available for both the PC and Mac computer lines. Many of these, such as Turbo Pascal (for both the PC and Mac) support an extensive set of graphical routines. Traditionally, the most common languages used to write graphics applications are FORTRAN, Pascal, and C. The rich, graphical environment of GUI systems has inspired object-oriented graphical languages like Visual Basicin which the programmer can create sophisticated multiple-window user interfaces without writing any code. Other languages such as LISP, Scheme, Prolog, Forth, and SmallTalk also offer strong graphics support, but have not been as widely adopted for graphical application programming.

We have selected Pascal to introduce graphics programming concepts, and later will introduce Visual Basic to illustrate the concept of an event-driven graphical language. The reasons for emphasizing Pascal are the following:

A number of excellent Pascal compilers are available for both the PC and the Macintosh. Turbo Pascal for Windows and THINK Pascal for the Macintosh share the features of a fast compiler and linker, an integrated text editor, and an object-oriented development environment. Their intelligent compilers understand the relationships between program modules, and, when sections are changed, they will recompile only the necessary dependent code. This greatly improves program debugging and development efficiency. The debuggers provide breakpoints, single stepping, and variable window for observing and changing the value of variables while the program is running.

Table 2.2
WINGZ Special Functions
Number of Functions

Level 1 Graphics Software- Spreadsheet Graphics

Two software tools of great value for computer users in general and technical analysts in particular are graphical spreadsheets and paint/draw programs. Several excellent graphical spreadsheets are on the market, including MS-Excel, Quatro Pro, Full Impact, MS-Works, and WingZ. We have selected WingZ as the illustrative spreadsheet for this text because of its speed, capacity, power, and graphics capability. It is one of the fastest spreadsheets available anywhere. It has a capacity of 32,768 rows by 32,768 columns and offers over three hundred special functions for performing operations on data with twenty different graph types for plotting it.

The breakdown of the functions by logical category is presented in Table 2.2.

Table 2.2 was created by WINGZ itself. Spreadsheets employ the very powerful metaphor that every cell in a 2D matrix array may be any function of any other cell or cells.

Figure 2.18
Segment of WINGZ spreadsheet. Rows range from 1 - 32,768 and columns range from A - AVLH. Tools for creating graphical objects are shown as icons on the left. 


To illustrate the ease of operation with spreadsheets, consider the following simple steps used in creating this table and computing the total given in the last line. WINGZ opens as a blank spreadsheet shown in Figure 2.18. The next step in creating the spreadsheet is to use the cursor to widen column A to accommodate the category text. After this formatting is done, the text and numbers are entered as shown. Pull-down menu commands are issued to center the heading and column B, convert the numbers into integers, and change the heading to bold face.

The total is computed by moving the cursor to B-12 and entering the function command, "=sum(", then by dragging the cursor from B-3 to B-11, and finally by typing a ")". The contents of cell B-12 then reads "=sum(B3..B11)." Upon hitting a <cr> the total, 307, magically appears in cell B-12. The final spreadsheet is shown in Figure 2.19. This table was selected by dragging the cursor from A-1 to B-12, executing "COPY" from the pull-down menu, switching to the word processor on which the text was written, and executing "PASTE" into a 12  x  2 table.

The beauty of graphical spreadsheets is the ease with which complex functions can be evaluated and visualized. Consider, for example, the following equation which corresponds to a damped, circular cosine wave.

z = cos(4 pi r) e-r                          [2.1]
r = SQRT(x2+y2)

= radial distance from impact

z = height of wave

e-r = exponential damping term


Figure 2.19
Image of final spreadsheet that was pasted into the text. Operations needed to build the spreadsheet included reformatting, data entry, and executing the "sum" function in B-12. 


Two design decisions must be made in order to map this function onto a spreadsheet.

To compute Equation 2.1, we position the cursor in cell A-1 and type in Equation 2.1 in spreadsheet syntax. This equation is shown in the upper entry box in Figure 2.20, along with a small segment of the resulting spreadsheet.

Figure 2.20
Spreadsheet calculation of damped circular cosine wave shown in Figure 2.21. 


The equation uses three resident WINGZ routines, "row()" to report the numerical value of the row in which the computational cell resides, "col()" to do the same thing for the column, and "pi()" to return the numerical value of pi. The numbers 26 and 25 are, respectively, the center offset and the normalization factors to implement the scaling described above. After hitting <cr>, the resulting number, 0.12, appears in cell A-1.

The second step in the process is to sweep the cursor from cell A-1 to AY-1, selecting the first 51 cells in the top row. Then, the menu command, "copy right," duplicates this equation in each of the selected cells. Finally, we select the first row through cell AY-1 and drag the cursor down to select all cells to row 51. The "copy down" command copies the key equation into all 51 x 51 cells. After a fraction of a minute, the numbers shown in Figure 2.20 appear. These numbers correspond to the z values of the wave equation 2.1 at all 2601 points in the (x,y) grid.

Three steps are required to generate a 3D graph from the numbers. First, we select (or leave selected) all 2601 cells. Second, we click on the graph tool (shown left of row 8 in Figure 2.19). Third, we create a graph box by dragging the cursor. The program does the rest. After minor adjustment of the vertical scale divisions and color key, the shade-encoded surface plot of Figure 2.21 appears. Notice the very sophisticated processing represented in this figure. It includes:

  • Automatic height-encoding by shading,
  • Automatic 3D perspective projection,
  • Automatic hidden-line and surface removal.
  • Figure 2.21
    WINGZ 3D surface plot of damped cosine wave. 


    These nontrivial operations will, in fact, be among the topics covered in Section 2 of this text. The graphics processing incorporated in this one application program constitutes approximately 95 percent of the subject matter covered in most conventional graphics textbooks.

    Level 1 Graphics Software - Painting/Drawing Programs

    MacPaint is the program that created the most interest and captured the imagination of creative artists and programmers alike at the unveiling of the original Macintosh. It is really a bit-mapped reincarnation of Ivan Sutherland's historic 1963 program, Sketchpad.

    Users totally unfamiliar with computer languages could now create original designs and poster art with minimum effort and have total flexibility in manipulating the bit-mapped screen. In addition to a simple etch-a-sketch-like capability, MacPaint offers graphics functions for drawing lines, rectangles, polygons, and ovals. By applying constraints to these functions, fixed angle lines (45 degree increments), squares, and circles are easily constructed. The program also offers a variety of pen shapes and patterns, a spray can for special effects, and a paint option for filling areas with shades of gray or special patterns. The tool palette and the result of applying some of these functions are shown in Figure 2.22.

    The message, "Hi there!," in this figure was written with the paintbrush tool and mouse. The rectangle, rounded rectangle, oval, and irregular object were created with the respective tools in the left hand column. The little house was created with the lower left hand polygon tool to draw the end of the house and the line drawing tool to draw the roof and side. They were then filled using the paint can tool and appropriate patterns from the pattern palette shown at the bottom of the screen. The whole screen painting operation took about two minutes.

    The most intriguing feature of MacPaint is its fast bit-mapped editing functions. These include the lasso, marquee, hand, pencil, and eraser tools near the top of the tool palette, and the duplicate function under the edit pull-down menu. Using the images in Figure 2.22 as the starting point, the edited image in Figure 2.23 was easily generated.

    First, the upper right hand marquee tool was used to select and cut the word "there!." It was also used to select the word "Hi" and slide it to the right. The word "there!" was then pasted from the clipboard and dragged into its present position. Next, the rounded rectangle was selected by the lasso and dragged on top of the rectangle, and this process was repeated for the oval and the irregular figure. The figure was then painted by the speckled pattern. Finally, the house was selected by the lasso tool and duplicated two times. The right-hand copy was generated by selecting one of the copies with the marquee tool and calling the menu function Flip Horizontal to draw the house shown.

    Although it is a simple and easy to use program, MacPaint has some very sophisticated image processing functions. These include an edge detector and the fat bits editing option in which the user can easily edit individual pixels to refine the image to the limit of the screen resolution (72 pixels/inch).

    The second major class of level 1 paint/draw programs are the drawing programs exemplified by MacDraw which is marketed by Claris Corporation. While some of the palette tools have the same shape and function as painting programs, drawing programs differ in a very fundamental way. This distinction can best be understood by distinguishing bit-mapped images from object-oriented images.

  • Bit-mapped images - Once the image element is painted or pasted on the bit-mapped screen, it becomes part of the composite image and loses all of its individual identity. All "objectness" of the element is lost once it is drawn or pasted. If an image element is manually selected by the marquee or lasso tool and dragged elsewhere, it leaves behind blank white space where it formerly resided. That is, it is no longer a graphical object, but rather just a (possibly incomplete) pattern of pixels.

  • Object-oriented images - Images created by the tools in object-oriented drawing programs maintain their identity and "objectness" throughout the lifetime of the scene of which they are a part. Individual objects may be grouped to construct more complex objects, and complex objects may be disassembled into their individual parts and the parts edited or deleted. Objects are selected by simply clicking on them and may be moved, re-sized, and manipulated in any number of ways.
  • Figure 2.22
    MacPaint tool palette and sample output. 


    Figure 2.23
    An edited version of Figure 2.22. 


    A little reflection on these two differing graphical paradigms suggests that each is most appropriate for certain classes of tasks. Painting programs are best suited for creating artistic images involving shading, complex patterns, and impressionistic effects. Drawing tools are best suited to engineering and design applications in which geometric objects form the basis and precision gridding and dimensioning are important.

    A number of excellent programs have emerged which combine the best features of both painting and drawing programs. Among these are SuperPaint and Canvas. Figures 2.6-2.9, 2.11, 2.16, and 2.17 were created using Canvas. By providing accurate dimensioning options and the capability of stacking objects on top of other objects, programs such as Canvas really qualify as 2D CAD tools. We will return to these tools in more detail in the applications section.

    Level 2 Image Processing Software

    The integration of computer graphics, image processing, pattern recognition, and scientific visualization has led to a whole new class of image processing software. While no single program is capable of all possible functions, some program generally provides the required feature. The most common image processing operations include: brightness and contrast adjustment, color palette selection and manipulation, image smoothing and sharpening, blurring and edge detection, dithering and halftoning, and the negative transformation.

    In addition to the mathematical operations on images themselves, a host of programs are available for the generation and realistic rendering of 3D images. These programs fall under the category of 3D drafting, CAD, and rendering applications. We examine them in greater detail in the applications section.


    The issue of standards is problematic in computer science and, in particular, in computer graphics. The benefits derived from the adherence to standards include transportability, simplicity, and efficiency. Data files adhering to standard formats are easily transportable between applications programs, and programs written in standard languages are easily transported between different machines.

    The "down side" of standards is that they are made to be broken. That is, a strict adherence to the standard(s) in effect at a given point in time forbids the introduction of innovative new techniques and extended capabilities. To the extent that the standards are "dynamic" in adapting to new hardware and software capabilities, their value as standards is lost. In a rapidly expanding field such as computer graphics, standards are particularly problematic.

    Before turning to case studies and the discussion of graphics standards, two classes of standards should be distinguished. They include:


    Case Studies

    Consider the following case studies which illustrate both the advantages and difficulties with standards.

  • Standard character codes - The American National Standards Institute has specified the American Standard Code for Information Interchange (ASCII) as the standard 7-bit collating sequence for representing the alphanumeric character set. This standard has been nearly universally accepted by hardware manufacturers. As a result, communication between machines of different types is painlessly accomplished by the exchange of ASCII text files. The primary deviation from this standard was IBM's Extended Binary Coded Decimal Interchange Code (EBCDIC), an 8-bit code of which ASCII is a subset.

  • Standard Pascal - The accepted standard for the Pascal language is the American National Standard Pascal (ANS Pascal). Since the establishment of this standard, many new Pascal implementations have appeared which keep ANS Pascal as a subset but extend the language by the addition of useful data types and graphics functions. Both Turbo Pascal and THINK Pascal, for example, have relaxed some ANS Pascal restrictions and added various useful extensions, among them:
  • New data types: longint, double, computational, and extended,
  • String-types and string handling functions,
  • Units for modular construction and compilation of programs,
  • Object Pascal to support object-oriented programming,
  • Access to the Macintosh Toolbox of graphical functions.
  • By adhering to ANS Pascal as a subset, these dialects have retained the advantage of import compatibility, i.e., both Turbo Pascal and THINK Pascal will run programs written in ANS Pascal. However, by adding extensions, they have lost export compatibility--Turbo and THINK Pascal programs making use of extensions most likely will not run under other Pascal dialects.

  • Graphical Display Standards - Perhaps the prime example of the value and problem of standards is the history of the de facto graphics display standards established by IBM for its PC line and adhered to in varying degree by PC clones. The first standard was the Color Graphics Adapter (CGA) giving 320 x 200 pixel resolution in 4 colors. The first significant deviation (extension ?) to this standard was the Hercules monochrome card which provided 720 x 350 pixel resolution in black and white. This was particularly welcomed by users doing word processing. Next came the IBM Enhanced Graphics Adapter (EGA) card which provides 640 x 350 pixel resolution in 16 colors. This standard was challenged by IBM's own Professional Graphics Controller (PGC) card which gave 640 x 480 pixel resolution in 256 colors. Both EGA and PGC were soon displaced as the state-of-the-art standard by the Video Graphics Adapter (VGA) giving 640 x 480 resolution in 16 or 256 colors, depending on card memory. The VGA standard is rapidly giving away to Super VGA with a resolution of 1024 x 768 pixels.

    The establishment of these de facto standards has served a very useful function in providing specifications for second source hardware manufacturers. However, it has also caused headaches for software houses which had to write interface modules for a nearly infinite number of combinations of CPU/interface card/monitors. As a result, software was bulky and cumbersome, and incompatibilities quite common. A typical graphics-dependent application program requires the user to run a "twenty questions" installation program to specify the system configuration. The Macintosh has cleverly avoided such compatibility problems by establishing the Macintosh User Interface Guidelines, enforcing them, and interpreting the hardware configuration invisibly at the system level.

    What can we learn from these case studies of standards? The first lesson is that standards achieve their maximum value to the extent that they are widely adhered to and stable over time. The experience with ASCII character codes illustrates this lesson. The second lesson is that standards in dynamic areas of technology are made to be broken. A slavish acceptance of standards can actually impede technological development. The dynamic field of IBM graphics standards demonstrates this. Finally, the value of standards in relatively static areas such as high-level language may be to provide a stable base on which to build powerful extensions.

    Graphics Standards

    We finish this chapter with a discussion of graphics standards and the role they play in the technological basis of visualization. While the above three case studies of standards are all of interest to computer graphics programmers, of even more immediate concern are the standards for graphics image file formats and graphics implementation languages.

    Graphics Image File Formats

    Just as the ASCII standard permitted the smooth flow of alphanumeric data between various application programs and various machines, the goal of graphics image file format standards is to facilitate the flow of graphical data between machines and among application programs on a given machine. To the extent that standard graphics image file formats are developed and widely accepted, we can manipulate complex graphics files as easily as we now do text files.

    Two general classes of image file formats have emerged with differences which reflect the distinct nature of the images they represent. These two classes can be labeled as pixel-mapped and object-oriented.

  • Pixel-mapped formats - Pixel-mapped file formats reflect the MacPaint-like nature of the image. That is, if each of the 512 x 342 pixel values (= 0 or 1) of a B/W Macintosh is specified, the image is completely specified. For color displays, each pixel requires 1, 2, or 3 bytes depending on whether you are encoding 8-, 16-, or 24-bit color. Pixel-mapped formats are of particular value in storing video and digital scanner generated images. We discuss here the GIF and TIFF formats.

  • Object-oriented formats - Just as drawing and CAD programs generate their images from precisely defined geometric objects, files used to represent the resulting images are most efficiently encoded by recording commands for generating the objects themselves. Unless the drawing is extremely complex, this scheme should be more economical in use of disk space than simply recording the color of each pixel as do pixel-mapped formats. Another advantage of object-oriented formats is that they accommodate the difference between screen resolution and output device resolution, optimizing the image for both. The object-oriented file formats of interest to graphics programmers include DXF, EPS, IGES, NAPLPS, and PICT.
    GIF - Graphics Interchange Format

    The GIF de facto standard is a device independent format developed by the CompuServe Information Service and H&R Block Company for the distribution and exchange of images over the network. It supports 8-bit color images up to 64K pixels on a side. Multiple images may reside on a file, and GIF provides very efficient packing and unpacking of files using the Lempel-Ziv & Welch compression algorithm. This is a valuable feature for transmitting files over a network or by modem.

    The field format of GIF files starts with a signature/version block followed by a logical screen descriptor block which specifies the screen height and width, whether or not a global color map exists, the color resolution, background color, pixel size, and aspect ratio. Next come two optional fields, the global color map and an extension block (tag field) which may be used for comments identifying the software or scanning equipment used to create the image.

    An image descriptor block follows which defines the top and left coordinates of the image and its height and width along with some control flags. Following this comes an optional local color map and a requisite raster data block containing a block byte count and the actual data bytes defining the image. The final data structures consist of optional extension blocks and a terminator. The actual byte assignment of each field in a GIF file is shown in Figure 2.24 and described by Graef.

    Although few image processing application programs support the GIF format, it is a convenient, fast, and efficient format for exchanging graphics files between graphics platforms. The display programs FastGif (on the PC) and Giffer (on the Mac) are in the public domain. File transfer between the PC and Mac is accomplished simply by connecting their serial ports and running any file transfer program or by reading and writing DOS-compatible files on the Macintosh.

    Figure 2.24
    GIF Image File Format. 


    TIFF - Tag-based Image File Format

    This de facto standard was conceived through a joint venture between Aldus Corporation and Microsoft to support digital scanner manufacturers and desktop publishing systems. The purpose of TIFF is to describe and store raster image data. Its features include the following:

  • Capability of describing bilevel, grayscale, palette-color, and full-color image data in several color spaces.

  • Support for a number of compression schemes that allow developers to choose the best space or time tradeoff for their applications.

  • Independent of specific scanners, printers, or computer display hardware.

  • Portability. It does not favor particular operating systems, file systems, compilers, or processors.

  • Extensibility to evolve gracefully as new needs arise.

  • Inclusion of an unlimited amount of private or special-purpose information.
  • As the name implies, TIFF files consist almost exclusively of tag data fields. Tag fields are blocks of data whose first element is a 2-byte tag, a unique identifying code which labels the field. The tag-field data structure provides a flexibility and extensibility that is helping TIFF become a standard for image storage and communication. The file format is independent of specific operating systems, processors, compilers, and filing systems. The only assumption is that the system storage medium supports files defined as a sequence of 8-bit bytes numbered from 0 to N. TIFF files may be as large as 232 bytes. Figure 2.25 presents the details of the file format.

    Figure 2.25
    Tag-based Image File Format (TIFF). One or more Image File Directories (IFDs) contain pointers to image objects. Offsets are measured in bytes to the referenced element. Details of the TIFF format are given in TIFF - Rev 6.0.


    The only positional field in TIFF is the 8-byte header which specifies the ordering of the bytes, the version number, and the offset to the first Image File Directory (i.e., how many bytes further down the file the directory starts). Next comes the first Image File Directory containing 12N +2 bytes for a TIFF file with N tag-fields. Then additional directories appear for multiple image files following tag-fields which may be included in any order. Each entry in the directory contains the tag, a specification of the data type, the length of data in the tag-field and a pointer to the tag-field location on the file. Version 5.0 of TIFF supports up to 45 tag-fields for storing all essential and informational data concerning the image. In addition to the essential information on image dimensions, color palette, and pixel map, TIFF records information on the specifications of the machine on which the image was generated, the software used to generate it, and the image aspect ratio.

    As users and developers extend the tag-image fields to enhance the image or incorporate new image specifications, they are encouraged to register the new tags with Aldus to preserve the uniqueness of the tag-field information.

    CAD File Formats

    Standard computer-aided design formats include:

    For object-oriented graphics applications, it is frequently more efficient to store a description of how to draw the image rather than the image itself. This becomes obvious when considering an image of a single line from the lower left hand corner of the screen to the upper right hand corner. A naive pixel-mapped B/W image would require storing a "1" or "0" for each pixel of the image; an object-oriented file would simply specify the object type ("LINE" as a DXF object) and the (x,y) coordinates of the beginning and end points of the line. Thus, instead of specifying 640 x 480 pixel values to represent the line, an object- oriented file can store its image as a short string and four numbers--a great savings in file space!

    A second advantage of object-oriented representations of well-defined graphical objects is that they are screen and output-device independent. This enhances the transportability of object-oriented files and exploits the full resolution capabilities of the current output device. For all of these reasons, object-oriented files are the preferred standard for drawing and CAD programs. Three of the most widely used object-oriented CAD file formats are the ANSI standards, NAPLPS and IGES, and the de facto industry standard, DXF.

    NAPLPS offers a wide range of graphical commands for encoding features such as geometric shapes, text scaling and rotation, color palettes, and mosaic graphics. Because graphical objects are encoded in a simple, straight-forward way, they may be decoded rapidly. This speed allows NAPLPS to be used as a format for simple animation displays. However, since video and digitally scanned images contain no well-defined mathematical objects, NAPLPS is not an appropriate format for storing such images.

    IGES is another ANSI industry standard widely used by workstation, minicomputer, and mainframe-based CAD applications. DXF is the file format widely used for exchanging CAD files between AutoCAD, the leading CAD system, and other CAD programs. A number of translator programs have emerged for converting between various CAD file formats. One of the first programs available for the Mac was CADMOVER by Kandu Software. The Apple Computer spin-off company, Claris, has released Claris Graphics Translator (CGT) for interconversion between MacDraw, PICT, IGES, and DXF files. International Microcomputer Software, Inc. markets the Graphics Transformer program which runs on MS-DOS machines and is capable of interconversion between essentially all graphics file formats on both DOS and Mac machines.
    PICT - The Macintosh Object/Image File Format

    Apple Computer Corporation has developed a proprietary file format for handling both object-oriented images and images from scanners and video digitizers. The first version of this format, PICT, encoded bit-mapped images in terms of QuickDraw commands; version 2, called PICT2, has a virtually identical format but encodes the images in Color QuickDraw commands. A convenient mental image of a PICT file is that of a recording of the QuickDraw commands required to draw an image. If the series of commands is issued directly to the computer, a standard QuickDraw image appears. If the series of commands is saved to a file and played back later, the same image appears. The file in which these commands are stored is the PICT file.

    In Figure 2.26, the general structure of a PICT file is illustrated. The file structure consists of a fixed length header containing application-specific information including size, scaling and version. Following the 512-byte informational header comes a 2-byte picture size field and an 8-byte picture frame field ([x,y] for top, left, bottom, and right corner). The main body of the PICT file is a sequence of op-codes and arguments for encoded QuickDraw commands to reconstruct the image. Op-codes are 2-byte (4-digit hexadecimal) commands such as: fill pattern = $000A, Line = $0020. and paintOval = $0051. Immediately following each op-code command is its argument, shown in the figure as picture data. Depending on the complexity of the data, arguments range from 0 - 12 bytes in length. The final field of a PICT file is the opEndPic = $00FF command. Byte-level details of the PICT file structure are given in Inside Macintosh, Vol. V.

    Figure 2.26
    PICT File Format. Note the "macro-like" structure of op-code followed by image data. Opening a PICT file corresponds to playing back the sequence of graphics commands encoded in QuickDraw op-code commands. 


    Clearly PICT files can range greatly in their complexity and length. PICT files are opened by the QuickDraw OpenPicture routine, closed by the ClosePicture routine, and displayed using DrawPicture. PICT files are very efficient formats for encoding object-oriented images and, a bit surprisingly, also efficient for storing general image information from scanners. They share the device-independent, high-resolution advantages of strictly object-oriented file standards and retain the generality of pixel-mapped standards such as TIFF files. PICT is a proprietary Apple format that has become the de facto standard within the Macintosh community.

    EPS - Encapsulated PostScript Files

    POSTSCRIPT by Adobe Systems has become one of the most successful graphics languages. We examine some of its features in the next section. Just as PICT files encode a sequence of QuickDraw routines which generate an image, so EPS files encode a sequence of PostScript commands to generate an image. Since EPS commands are machine- and device-independent and supported by all PostScript equipped printers, the PostScript language has become a new de facto standard. And since EPS files are essentially "recordings" of PostScript commands, we turn next to the subject of graphics language standards.

    Graphics Implementation Languages

    The goal of a graphics implementation language (GL) is to provide a standard set of graphics functions and procedures which span the range of hardware and software systems. The objectives of an ideal GL standard should include:

    Building a GL standard which satisfies this set of enormously difficult goals has proven insurmountable to date. First, we consider some of the problems, then some of the technological breakthroughs which are helping resolve these problems, and finally a discussion of the major standard GLs and their features.

    The problems which have bedeviled the attempts at implementing a GL standard include:

    A number of technological breakthroughs promise to resolve many of the most serious problems and facilitate the development of a standard graphics language. The most promising of these include: To understand the present state of affairs one should know something of the history of GL standards. Some of the major languages which have been proposed and, in some cases, adopted as graphics standards are summarized below. Additional information on the history and features of computer graphics languages is presented by Rankin.
    CORE System

    By 1977 the proliferation of graphics systems and the complete lack of any graphics language standards led ACM's Special Interest Group on Computer Graphics (SIGGRAPH) to propose the CORE standard. In 1979 the graphics standardization activities started by SIGGRAPH were turned over to ANSI which formed committee ANSI X3H3 with considerable membership overlap from the original SIGGRAPH committee.

    The CORE standard never received final approval as an international graphics standard language. However, much of the logical framework and syntax proposed in CORE survives as the basis for subsequent approved standard languages. For instance, CORE proposed the classification of logical input devices: button, pick, keyboard, valuator, locator, and stroke - the scheme subsequently adopted by the international standard GKS. Many of the CORE commands (e.g., setwindow, lineabs2, moverel2) provided the model for subsequent graphics languages from Borland's PC Turbo Graphix Toolbox to the Macintosh QuickDraw routines.

    Since CORE is a very large system encompassing both 2D and 3D graphics, many graphics authors have chosen a simpler subset of the language for illustrating their texts. However, because it was issued before the advent of bit-mapped color graphics, CORE does not support any of the fill and pattern commands widely available on modern workstations. It also does not support the high-level arc, oval, and spline commands which many systems provide as intrinsic functions. Students of graphics should be aware of the contributions CORE has made to the standardization enterprise, but we shall not consider it further in this book since it is not supported on graphics workstations.

    GKS - Graphics Kernel System

    The initial design of GKS began in Germany in 1975, about the same time that work began on the CORE system. After 7 revisions, an enormous amount of work by an active core of about thirty people, and the participation of about 100 experts from sixteen nations, the GKS standard was accepted by the ISO and published ten years later in 1985. JosÈ EncarnaÁÑo was the chairman of the first DIN-GKS committee and prime mover in the early development of GKS. The fascinating history of this development and some considerations which went into the design of the GKS are spelled out in detail by Enderle, Kansy, and Pfaff.

    Some of the design issues which were considered include:

    This brief glimpse at the issues confronting those defining the GKS graphical language standard illustrate the problematic nature of standards. By homogenizing the language so that it becomes acceptable to everyone and runs on all machines, you must make compromises which discard some of the highest-level graphics options available. The result lacks the innovative features of "cutting-edge" technologies.

    In addition, to implement GKS on any given system, it is necessary to write the GKS functions in terms of the intrinsic system functions, many of which may be equivalent to, or even more powerful than, the corresponding GKS function. This adds another layer of code to any graphics application with the inevitable result of system degradation. Since many graphics algorithms are already compute bound, this may be an unacceptable price to pay for the transportability that a standard language offers.

    These comments are not meant to disparage the great accomplishment that GKS represents. The language meets most of the criteria set out earlier in this chapter as ideals for any standard. One of the most important contributions of GKS was the careful study of issues influencing the design of graphics standards and languages. It also strongly influenced the design of subsequent graphics standards (e.g., PHIGS) which emerged to overcome some of the limitations of GKS.

    PHIGS - Programmer's Hierarchical Interactive Graphics Standard

    PHIGS is the reincarnation of CORE with special attention to hierarchical segmentation and full 3D functionality. It was developed by a committee of the American National Standards Institute and has been approved as an ANSI standard. Several features distinguish PHIGS. Its object-oriented segmentation structure contains graphical primitives, attributes, and transformations, all of which may be edited interactively. Segments may be referenced or copied from other segments, thus requiring only one copy of the original segment. Attributes of a supersegment are placed on a stack when a subsegment is executed and restored when the lower-level execution is completed. This hierarchical segmentation structure provides for great flexibility and efficiency of image storage.

    PHIGS takes great care to distinguish the building and manipulation of graphical objects, on the one hand, from their display, on the other. The creation of graphical objects, called modeling, is done in a device-independent way, and the GKS-like functions used to model the data are placed in a centralized structure store (CSS). When the modeling is complete, the modeled structure is posted, i.e., sent to a display or output device. Thus the machine-dependent device drivers may be completely isolated and confined to the posting function. This paradigm closely resembles that used by the POSTSCRIPT language.

    A somewhat more controversial feature of PHIGS is the monolithic nature of the system. It does not permit the "tool box" metaphor of assembling small, efficient, special-purpose systems by pulling functions from the toolbox. Thus, it is difficult to build a simple 2D subset of the PHIGS language. We have attempted, however, to use the PHIGS nomenclature and philosophy in the construction of FIGS (Fundamental Interactive Graphics System), a subset of PHIGS used to build a GUI application program in the chapter on designing graphical user interfaces. Appendix B specifies the FIGS routines and calling sequence in detail.

    The design criteria in building PHIGS explicitly specify that it is to be a super-set of GKS. That is, for all features with similar functionality, PHIGS defaults to the syntax and behavior of GKS. Thus, nearly one hundred of PHIGS's three hundred functions have identical names and functionality as the GKS 2D functions. This is good judgment not only from a standards engineering perspective--it also served to enhance its acceptability to the ISO committee which recently approved it as a standard. The attempts to harmonize the PHIGS and GKS standards are discussed at some length by EncarnaÁÑo, the guru of GKS.

    PHIGS PLUS is a proposed extension which provides more advanced graphical modeling and rendering capabilities. It is under consideration as an international standard by the ISO. Some of the additional features offered by PHIGS PLUS include:

    Neither PHIGS nor PHIGS PLUS is yet capable of producing photorealistic images since they lack features for rendering shadows, reflections, transparency, and surface textures. However, the extensions of PHIGS PLUS generate much more pleasing and useful output for practical applications in design and engineering. An excellent introduction to PHIGS and PHIGS PLUS is given in Howard et al. A commercial version of PHIGS, called FIGARO+, is described in an extensive manual and is available for a variety of graphics and UNIX workstations.


    Of the examples considered here, POSTSCRIPT comes the closest to the criteria for the ideal graphical language. John Warnock, its author, describes the evolution of the language through three stages: its origin as the Design System from his work at the Evans & Sutherland Computer Corporation beginning in 1976, its development as JaM (for "John and Martin") from his work with Martin Newell at Xerox PARC beginning in 1978, and its culmination as POSTSCRIPT in 1982 when he and Charles Geschke incorporated Adobe Systems to market the language.

    Through the cooperation of Warnock and Steven Jobs of Apple Computer, POSTSCRIPT was selected as the printer driver for the Apple LaserWriter. The combination produced printed output of near typeset quality, and the desktop publishing industry was born. Soon POSTSCRIPT drivers were available for Linotronic printers as the output device for the Macintosh, thereby making available true type-set quality and extremely high-resolution graphics. POSTSCRIPT has spread to many other computer systems and is rapidly becoming the de facto standard graphics language.

    Let's look at some of its features.

    It is interesting that POSTSCRIPT has achieved such phenomenal success as a de facto standard, while the major international graphics standards are "lumping along." POSTSCRIPT is well ahead of the other standards in its total flexibility in handling text and its capability for processing sampled images. However, it is not yet the complete answer to the graphics programmer's needs. Missing features include:  

    X Windows

    While it is neither strictly a graphics language nor a graphics file format, X Windows has become one of the most important standards in computer graphics. It can perhaps best be described as a system for the communication and manipulation of graphical information in a network environment. The X Windows system grew out of MIT's Project Athena, an experiment in the use of networked graphics workstations as a teaching aid. The Athena team released X Windows into the public domain, and it was so successful that Hewlett-Packard and DEC designed new workstations around it.

    In 1988, a consortium was formed, including MIT, Apollo, Apple, AT&T, DEC, HP, IBM, Sun, Tektronix, and other leading manufacturers, to establish X Windows as an ANSI standard. The X Consortium froze the X Windows specifications through 1991 at the X11 level in order to fix its bugs, add 3D extensions to support the PHIGS standard, and obtain ANSI approval.

    What are some of the features of the X Windows System that has led to this success?

    X Windows is not designed for stand-alone workstations running a limited number of commercial application programs. To the extent that workstations connect to networks of heterogeneous platforms, however, X Windows demonstrates the value of standards by offering a proven system for integration and communication of graphical information.


    The power of modern computer graphics workstations is optimized through the careful integration of hardware, software, and graphics standards. As a result of the exponential improvement in performance/price ratio, high-performance workstations are readily available for less than $10K and capable instructional systems cost well under $2K. The technological basis of computer graphics is caught up in a three- stage positive feed-back loop: The surge in high-performance hardware has led to the development of a plethora of excellent drawing, drafting, CAD, image processing, and desktop publishing software, which has, in turn, driven the evolution of graphics file and language standards. The acceptance and use of de facto standards such as PICT, TIFF, and EPS files and the POSTSCRIPT language has resulted in widespread generation and dissemination of graphical data. This, in turn, increases the demand for more and better hardware--and the cycle continues. This survey of the technological basis of visualization should help the reader understand the graphics industry and better evaluate the professional opportunities it offers.