The following paper was originally published in the Proceedings of the Conference on Domain-Specific Languages Santa Barbara, California, October 1997

Programming Language Support for Digitized Images or, The Monsters in the Closet

Daniel E. Stevenson and Margaret M. Fleck University of Iowa

For more information about USENIX Association contact: 1. Phone: 510 528-8649 2. FAX: 510 548-5738 3. Email: [email protected] 4. WWW URL:http://www.usenix.org

Programming Language Supp ort for Digitized Images

or, The Monsters in the Closet

 y

Daniel E. Stevenson Margaret M. Fleck

Department of Computer Science Departmentof Computer Science

University of Iowa University of Iowa

Iowa City,IA 52242, USA Iowa City, IA 52242, USA

Abstract rapid spread of images is particularly obvious on the

World-Wide Web.

Although many users require only image pro cessing

Computer vision image understanding algorithms

and graphics packages e.g. xv, Photoshop, an in-

are dicult to write, debug, maintain, and share.

creasing range of applications require basic image

This complicates col laboration, teaching, and repli-

understanding. For example, researchers in the sci-

cation of research results. This paper shows how

ences and medicine use images to measure physical

user-level code can be simpli ed by providing bet-

prop erties e.g. blood vessel width and screen for

ter programming language constructs, particularly

interesting events e.g. unusual cell shap es. Com-

a new abstract data type cal led a \sheet." These

panies, governments, non-pro t organizations e.g.

primitives have been implemented as an extension

museums, and private citizens are converting photo

to Scheme.

collections to digitized form. They require e ective

Implementation of sheet operations is made chal-

ways to lo cate images with sp eci c content in large

lenging by the fact that images are extremely large,

databases.

e.g. sometimes over 5 megabytes each. Therefore,

Computer vision lies on the b order between com-

operations that loop through images must be com-

puter science and electrical engineering. Tradition-

piled from a specialized subset of  Scheme into C.

ally, it has b een isolated from the rest of computer

This paper discusses how the need for extreme e-

science. In particular, it has seen little b ene t from

ciency a ects the design of the user-level language,

recent advances in the design and implementation

the run-time support, and the compiler.

of programming languages. Computer vision algo-

rithms are still written primarily in C, o ccasionally

now in C++.

1 Intro duction

As a result, computer vision co de tends to b e com-

plex and rep etitive. It is dicult to write, debug,

maintain, and share. Inability to replicate results re-

Within the past few years, computer imaging equip-

p orted in research pap ers, which is the norm rather

ment has b ecome dramatically cheap er and more re-

than the exception, is a ma jor barrier to progress

liable. Six years ago, a color camera and framegrab-

in this sub eld. Collab oration with researchers in

ber cost $15,000 and was to o heavy to lift. It can

other areas of computer science is almost imp ossi-

now be replaced by a $400 hand-held digital cam-

ble.

era. As a result, cameras are b ecoming widely avail-

able. Both programmers and researchers are start-

More signi cantly, many computer vision algo-

ing to incorp orate images into computer science ap-

rithms are not much easier to program in high-level

plications remote from the traditional home of im-

languages in practice, always Common Lisp. O -

ages, computer vision image understanding. The

the-shelf compilers and interpreters do not provide

the required eciency. And the high-level language



Now at the University of Wisconsin{Eau Claire, Eau

co de tends to resemble a word-for-word translation

Claire, WI 54702

y

Now at Harvey Mudd College, 301 E. Twelfth St., Clare-

of the C co de. Existing abstract data typ es and con-

mont, CA 91711

trol constructs do not match the rep etitive structure ically stored as packed bytes, b oth in memory and

in this co de and, therefore, cannot b e used to sim- in disk les, even though they are conceptually real

plify it. numb ers. Allo cation and deallo cation must b e un-

der user control, b ecause images do not naturally

This pap er will present new abstract data typ es

b ecome garbage in the sense of b ecoming inacces-

and asso ciated op erations. These primitives, imple-

sible to the user quickly enough to prevent mem-

mented as an extension to Scheme [3], encapsulate

ory from lling up. They must b e allo cated outside

much of the rep etitivework common in computer vi-

the heap in a language suchasScheme, to prevent

sion co de and can b e compiled into ecient C co de.

heap fragmentation and unnecessary copying of im-

We will discuss key issues involved in implementing

age data. And it must b e p ossible for related images

the required compiler and run-time supp ort, com-

e.g. an image and a subimage to share storage.

plementing previous work on compiling Scheme into

C. And we will suggest how some of the features Finally, algorithm designers must b e extremely care-

required in computer vision might nd wider appli- ful ab out how image data moves within the com-

cation in programming language design. puter. Scanning through an image in the wrong or-

der, on a machine with insucient RAM, can cause

dramatic swapping. Op erations such as image rota-

tion, which must access their input and output in

di erent orders, sometimes require that very large

2 Images are huge!

images b e divided into subblo cks. Even if there is

enough RAM, swapping could still o ccur inside in-

The most distinctive feature of digitized images is

ternal memory caches.

their size. Digital cameras sold for the home PC

When image pro cessing or image-related graphics

market deliver 24-bit color images at sizes ranging

is done on an external b oard, transmitting image

from 320 by 240 up to 1600 by 1200. When the

data between the b oard and main memory is of-

data is stored in packed binary arrays, this trans-

ten a signi cant fraction of total running time. Bus

lates into between 0.23 and 5.76 megabytes per

sp eed is one of the ma jor obstacles in using PC-

image. Images obtained from scanners or certain

based cameras. On ne-grained parallel pro cessors

sp ecialized cameras are even larger, as are video im-

e.g. the Connection Machine, transmission of the

age sequences and 3D images from medical scanners

image from the camera to the pro cessors may com-

e.g. MRI. Although they can b e compressed when

pletely dominate running time.

stored in les, images must remain uncompressed

during analysis.

Said another way, images are ab out 4-6 orders of

magnitude larger than most ob jects traditionally

3 Existing vision packages

found in a high-level language, and a single im-

age may be comparable in size to the entire heap

of a traditional Scheme session. Moreover, a typi-

A number of packages of standard image pro cess-

cal vision function manipulates several such images

ing data structures and op erations have b een devel-

e.g. two inputs and one output. Atypical interac-

op ed to aid research and teaching in computer vi-

tive user doing exp eriments will use up all available

sion. Some packages, such as the standard utilities

memory in an attempt to manipulate e.g. compare

xv and pbmplus, supp ort only simple image pro cess-

as many images as p ossible simultaneously.

ing and manipulation. Others, such as the HIPS Im-

age Pro cessing System [12], Khoros [10], Lab oImage

Because images are so large and many applications

[6], and Matlab [19], cover a full range of low-level

require fast resp onse e.g. tracking moving ob jects,

image pro cessing utilities. Finally, some packages

computer vision programmers are obsessed with ef-

o er supp ort for higher-level vision op erations: the

ciency. Only the most stripp ed-down algorithms

Image Understanding Environment IUE [11], KB-

are fast when iterated over all one million lo cations

Vision [7], Vista [14], The Iowa Vision System [4],

in an image. Hand-co ding critical functions in as-

OBVIUS [5], and the Radius Common Development

sembler has only recently b ecome rare. This is a

Environment [17]. Many large sites have at least one

harsh environment in which to test programming

in-house package. And additional packages are used

language metho ds.

to supp ort image understanding pro jects in scien-

ti c elds e.g. astronomy, biology, medicine. Toavoid wasting scarce space, image values are typ-

A typical computer vision package contains a li- b er of high-level op erations in each package is quite

brary of C or C++ image op erations and an inter- limited. They typically include only one mo dern

preted front-end language. The front-end language edge nder typically Canny's, one camera calibra-

is used to connect op erations together, to commu- tion algorithm invariably Tsai's, and a small se-

nicate with the user, and to implement high-level lection of vision algorithms edge segmentation and

\smart" parts of algorithms such as automatic pa- grouping, texture features, motion analysis, classi -

rameter setting and control of multi-stage or search cation.

algorithms.

3.3 How have they fared?

3.1 Front-end language

Although these packages are all well-intentioned,

Existing packages use a variety of front-end lan-

and incorp orate manyinteresting design ideas, there

guages, whose main common feature is that they are

is no real prosp ect that any of them will b ecome a

always interpreted. Some use the Unix shell HIPS

standard to ol used by most of the eld. Computer

or interpreted C-like languages Matlab. Others

vision algorithms are still the sub ject of active re-

Khoros, KBVision, IUE use a graphical front-end

search and there are many recent, rival algorithms.

language. Finally, one can use a high-level pro-

However, each package includes only one or two al-

gramming language, such as Common Lisp Iowa

gorithms for each task, often ones develop ed over

Vision System, OBVIUS, Radius, Scheme, or ML.

ten years ago. For example, most packages do not

We strongly prefer to use a mo dern high-level lan-

include an edge nder more recent than Canny's.

guage, b ecause they are more p owerful and simplify

collab oration b etween computer vision and arti cial

Furthermore, di erent packages o er qualitatively

intelligence.

di erent features. The b est choice dep ends on how

much money your site can sp end, howmuch memory

The choice of front-end language is largely indep en-

and disk space your machines have, what op erating

dent of which op erations are included in the library.

system you run, what applications you study med-

The Cantata data owinterface has b een used with

ical, satellite, etc., what theoretical approachyou

at least three packages of op erations Khoros, KB-

favor, what other software e.g. LISP you have,

Vision, IUE. At least two recent languages, Tcl/Tk

and whether you prefer a graphic or a textual front-

and the Elk [13] implementation of Scheme, were

end.

sp eci cally designed to provide front-ends for a wide

variety of applications.

In any attempt to address these problems, the most

comprehensive packages e.g. HIPS, IUE, KBVi-

sion have grown so large that they are dicult to

3.2 Op erations included in library

maintain and do cument. For example, the IUE con-

tains over 575 classes, has over 800 pages of do cu-

mentation, and consumes 500M of disk space [1]. A

All reasonably-designed vision packages supp ort a

single package satisfying everyone's needs would b e

range of basic image manipulation op erations such

imp ossibly large.

as display, cropping, rotation, altering greyscale or

colormaps, and image statistics. Image pro cess-

ing packages HIPS, Khoros, Lab oImage, Matlab

also supp ort linear ltering, some nonlinear lters,

4 A b etter approach

standard transforms particularly the Fourier trans-

form, and often simple edge detectors. However,

these packages do not have go o d supp ort for higher-

The diculties in designing packages stem from the

level op erations that manipulate edge-chains, fea-

fact that designers are attempting to standardize

tures, and geometrical ob jects.

at an inappropriate level of abstraction. Moreover,

standardization at the correct level requires the full Packages designed for computer vision include data

power of a compiler. Because there has b een little structures and pre-written co de for high-level vi-

cross-fertilization b etween computer vision and pro- sion op erations, either in the form of C++ classes

gramming language design, package implementers and macros IUE, KBVision, and Vista or Com-

have used only insuciently p owerful to ols: library mon Lisp classes and metho ds Iowa Vision Sys-

functions, classes, and macros. tem, OBVIUS, and Radius. However, the num-

4.1 The right level for standardization to make them do so: rep etitivework should b e done

by a computer.

Consider the case of the op erators that generate

texture features from a gray-scale image. Previ-

4.3 The value of compilation

ous packages have attempted to provide a standard

set of texture op erators. However, the literature

Our extension to Scheme, called Envision, uses a

contains a wide range of texture op erators, none

compiler to transform user-level Scheme co de into

of them haveentirely satisfactory p erformance, re-

ecient C co de. Considerable research has b een

sp ected researchers cannot agree ab out which ones

done on compilation of high-level languages and the

p erform b est, and new op erators are constantly b e-

newest Scheme-to-C compilers [9, 15, 16] p erform

ing prop osed. Since no consensus exists, standard-

quite well. However, these techniques have never

ization at this level is premature.

b een applied to generating computer vision co de,

The correct place to standardize is at a level where

partly due to lack of communication between pro-

there is a scienti c consensus. This allows the pro-

gramming language research and computer vision

grammer to haveasmuch supp ort as p ossible while

and partly due to the signi cant initial investment

making it easy to add new functionality and exp er-

of time required to write or adapt a compiler.

iment with new variations in algorithms. Standard-

Compilation o ers several advantages in this do-

ization at to o low a level C arrays makes the pro-

main. It allows library op erations to b e written in

grammer do most of the work by hand, while stan-

the same language used in the package front-end.

dardization at to o high a level image data struc-

Typ e inference can expand a small numb er of user-

tures, image pro cessing functions limits users to

level typ e declarations into typ e assignments for all

currently available techniques and discourages them

variables. We can eciently implement a new con-

from expanding the frontiers of science.

trol form scan which eliminates much of the work

Therefore, we must provide standardization and

of lo oping through all lo cations in a 2D image, with-

supp ort at the level of the basic data structures and

out requiring function calls inside these lo ops.

control constructs used to write the library functions

Finally, our compiler can automatically p erform a

in computer vision packages. This would make the

variety of optimizations section 9. Many of these

library functions simpler and easier to understand.

optimizations are common in hand-written vision

Then, each programmer could create a package cus-

co de. However, human programmers do not apply

tomized to their needs, by merging and mo difying

them consistently, they apply them in unsafe ways,

co de from standard libraries.

they use approximations with poor numerical be-

havior, and they do not adapt quickly to changes in

4.2 Many drops of water make a river

the hardware, op erating system, or C compiler. It is

safer and more ecienttocentralize such knowledge

in the hands of the compiler writer.

Many previous researchers have approached this as

a software engineering problem. Since each piece of

rep etitivework is conceptually simple, it should b e

4.4 The necessity of compilation

easy for mature programmers to do it. So, it should

be sucient to standardize programming practice,

It is tempting to think that the same e ect could b e so as to make everyone's co de compatible. And,

achieved without writing a new compiler, by using therefore, it should b e sucient to de ne a suitable

facilities such as classes, macros, and typ e de ni- set of macros, classes, and accessor functions e.g.

tions e.g. in ML. Unfortunately, current languages functions to extract value from di erent typ es of

and compilers seem to lack the power required to images.

de ne and optimize our new data structures and

This approach fails due to the sheer volume of

op erations.

p edestrian work required to prop erly write a low-

First, translating our high-level co de into a stan- level computer vision algorithm. Creative scien-

dard language requires rewrite rules which op erate tists, even junior ones and those doing applied in-

at compile-time so the output co de is ecient but dustrial work, quickly get b ored with rep etitivecod-

which are typ e-dep endent. At compile-time, Lisp ing. They will not take the time to make co de su-

and Scheme supp ort only typ e-indep endent rewrit- ciently general or p ortable. And it is inappropriate

ing macros. The typ e system in ML[20] seems to e.g. where a surface was o ccluded in one image.

lack a mechanism for parameterizing a typ e by one The user need not know the details of how this is im-

or more numb ers. This gives us no clean way to plemented using a standard array of unsigned 16-bit

write a rule which manipulates ob jects of varying integers.

geometrical dimension but which requires access to

their dimensions.

5.1 Features provided by sheets

Second, a central feature of Envision is that miss-

ing unavailable values are rst-class ob jects. For

example, a variable which normally contains a

Sp eci cally, the sheets provide supp ort for multi-

real value may o ccasionally be assigned a missing

dimensional values, arbitrary ranges of lo cations

value. Handling missing values requires mo di ca-

and values, continuity, user-sp eci ed precision, cir-

tions to typ e inference rules, mo di cations to stan-

cularity, partiality, shared storage, and restrictions.

dard arithmetic op erations, co de analysis to deter-

Multi-dimensional values: The domain of a

mine which expressions can never return a missing

sheet may be of any dimension. This capability

values, and restructuring expressions to minimize

is already provided by arrays. However, in addi-

the numb er of tests for whether a variable value is

tion, the values stored in a sheet may b e p oints of

missing. Standard compilers do not contain such

any dimension. The current implementation sup-

supp ort.

p orts 1D and 2D domains as well as 1D, 2D, and

3D values. There are several ways to simulate a

multi-dimensional co domain using arrays: the pro-

grammer need not rememb er which metho d is b eing

5 Sheets

used.

The use of multi-dimensional values allows the user

The rep etitive parts of low-level vision co de can b e

to represent a wide variety of image data structure

isolated and removed from user-level co de using a

with sheets. For example, a motion vector eld can

new data structure called a \sheet." Sheets rep-

b e represented using a 2D sheet with 2D co domain.

resent the large areas of packed storage found in-

The outline of a 2D image region can b e represented

side image representations. They provide substan-

using a list which contains, among other things, a

tial capabilities beyond those of arrays, but only

continuous 1D sheet with 2D values the x and y

capabilities on which there is considerable consen-

co ordinates of the curve.

sus in computer vision. Using sheets, it is easy to

construct any of the wide variety of image represen-

Range: The lo cations in a sheet maybeany rectan-

tations currently in use.

gular subsection of 1D or 2D space. For many appli-

cations, the origin of the co ordinate system should

A sheet represents a function between two spaces:

b e placed at the pro jection center of the image. By

a set of lo cations the domain and a set of values

contrast, arrays force the origin to lie in one cor-

the co domain. Each space is lo cally Euclidean:

n

ner of the image, requiring geometrical algorithms

every small neighb orho o d lo oks like a piece of IR

n

to constantly add and subtract o sets.

or ZZ . The function is represented to nite preci-

sion: values are only available at a nitely dense set

Similarly, the user can freely sp ecify what range of

of lo cations and are only known with limited pre-

values will be stored in the sheet. The user is not

cision. Each sheet contains homogeneous data: all

con ned to the limited selection of ranges provided

values have the same typ e and precision. This al-

by arrays e.g. unsigned integers, signed longs,

lows packed storage and optimization of compiled

oats nor do es the range have to start at zero.

co de.

Continuity: The domain and co domain of a sheet

Sheets provide a layer of abstraction which insulates

n

may be either continuous lo cally like IR  or dis-

the programmer from the details of how image data

n

crete lo cally like ZZ . Images have a continuous

is stored in arrays. The sheet app ears to contain

domain and co domain. Edge maps have a discrete

data of the typ e describ ed in mathematical sp eci -

domain and co domain. Color maps have a discrete

cations of the algorithm. For example, a log-p olar

1D domain, but a continuous 3D co domain.

stereo map might app ear to b e tubular, to contain

th

Sheets with discrete domain provide values only signed oating p ointvalues given to the nearest 20

at grid lo cations, whereas sheets with continuous of a unit, and to havenovalues for certain lo cations

domain provide values at any lo cation within the cated by storing a sp ecial reserved value in the array.

b ounds of the sheet byinterp olation. Sheets with Unfortunately, programs don't all use the same re-

continuous co domain provide values as real num- served value. Di erent arraytyp es e.g. unsigned

b ers, whereas sheets with discrete co domain provide short, signed long, oat require di erent reserved

values as integers. values. Most programs notably edge nders do

not handle missing values at all.

Arrays, by contrast, always have a discrete domain.

For the co domain, computer vision programmers are Shared storage: The packed storage area of a

forced to cho ose b etween two bad options: discrete sheet is separated from header information, suchas

integers with an appropriate precision or continuous scaling. Two sheets with di erent headers can share

reals with an inappropriately high precision thus the same packed storage. As a result, rescaling or

wasting memory. shifting a sheet do es not require extensive memory

allo cation or copying, just creation of a new mo di-

Precision: Numb ers used in computer vision have

ed header.

a known, nite precision, due to a combination of

quantization and contamination with random noise. Restrictions: The header information for each

When a sheet is created, the user sp eci es the pre- sheet includes a fo cus area, used to limit display

cision of the values to b e stored in it. This, together and scanning op erations section 6.4. Thus, a sub-

with the user's range sp eci cation, automatically section can b e extracted from a sheet by combining

determines the number of bytes used to store the a new header with the same packed storage.

value at each pixel. Similarly, the user sp eci es the

spacing b etween pixel lo cations.

When using arrays, the spacing between pixel lo-

5.2 How sheets improve programming

cations is always one unit. For the integer arrays

typically used in computer vision, this is also true

of the output values. This forces pyramid-based al-

gorithms, for example, to explicitly rescale values.

Certain packages provide supp ort for some of these

features, but this supp ort is partial and erratic. As

Circularity: A sheet's domain and/or co domain

a result, most programmers build their own ver-

may b e circular. The current implementation sup-

sions of features by hand. These implementations

p orts the following topological types: linear  at

are sp ecial-purp ose and incompatible with one an-

domain and/or co domain, circular domain e.g. a

other. They often use substandard metho ds, such

closed 2D region b oundary, tubular 2D domain

as bilinear interp olation.

e.g. a log-p olar image, toroidal 2D domain b oth

dimensions are circular, and circular co domain

Standardized supp ort allows simple and p ortable

e.g. an image whose values are angles.

user-level co de. It ensures that good metho ds are

used for standard op erations such as scaling and

The top ological typ e determines what happ ens if

interp olation, that these op erations are fully de-

a program attempts to access lo cations outside the

bugged, and that they are implemented using a

domain range, or store values outside the co domain

standard p ortable language e.g. ANSI C. It helps

range. For example, circular co domain values are re-

users write algorithms which handle the full range

duced to the right range using mo dular arithmetic,

of images.

whereas linear co domain values are approximated

with the closest value in the range. Interp olation of

Figures 1 and 2 show C and Envision co de for a typ-

circular values also uses mo di ed algorithms.

ical op eration. The Envision co de is shorter than

the C co de, despite its longer Lisp-style function

Partiality: Values may b e unavailable for some lo-

names. The C co de is restricted to 8-bit unsigned

cations in a sheet. This may happ en in the middle

values, whereas the Envision co de handles sheets

of the sheet e.g. o ccluded regions in stereo dispar-

with any range of values. The Envision co de uses

ity maps or adjacent to its edges e.g. an image

second-order, rather than bilinear, interp olation and

which has b een rotated or corrected for lens distor-

leaves smaller holes around missing values. It re-

tion. References to such a lo cation, or to a lo cation

quires fewer input arguments. And, it rotates ab out

outside the sheet's storage range, return a sp ecial

the image center, a meaningful user-level lo cation,

\missing" value.

rather than ab out the upp er-left corner of the stor-

In array-based co de, missing values can be indi-

age array.

void rewindow

bulk-define

double startx, double starty, double angle,

rewindow ; name

*char array1, *char array2, int xsize1,

manifold 2 1 ; input types

int ysize1, int badval1, int xsize2, int ysize2,

manifold 2 1 real real real

int badval2, int minval2, int maxval2

unspecified ; output types

{

lambda insheet outsheet xoffset yoffset angle

int newx, newy, lowx, highx, lowy, highy, intout;

let sinangle sin angle

double realx, realy, errorx, errory, v1, v2, v3,

cosangle cos angle

v4, sinangle, cosangle, interpolated_value;

scan location outsheet

sinangle = sinangle; cosangle = cosangle;

let*

for newx = 0; newx < xsize2; newx++ {

point sample->point location

for newy = 0; newy < ysize2; newy++ {

xcoord point-coordinate point 0

realx = startx + newx*cosangle + newy*sinangle;

ycoord point-coordinate point 1

lowx = floorrealx; highx = ceilrealx;

sample-set! location

errorx = highx - realx;

sheet-ref insheet

realy = starty + newy*cosangle - newx*sinangle;

+ xoffset

lowy = floorrealy; highy = ceilrealy;

* xcoord cosangle

errory = highy - realy;

* ycoord sinangle

if lowx < 0 || lowy < 0

- + yoffset * ycoord cosangle

|| highx >= xsize1 || highy >= ysize1

* xcoord sinangle

array2[newx * ysize2 + newy] = badval2;

else {

v1 = array1[lowx * ysize1 + lowy];

Figure 2: Envision co de for the same op eration.

v2 = array1[lowx * ysize1 + highy];

v3 = array1[highx * ysize1 + lowy];

v4 = array1[highx * ysize1 + highy];

Basic arithmetic op erations are extended to work

if v1 == badval1 || v2 == badval1

|| v3 == badval1 || v4 == badval1

transparently on higher dimensional p oints.

array2[newx * ysize2 + newy]

= badval2;

else {

6.2 Missing values

interpolated_value =

errorx * errory * v1 +

errorx * 1.0 - errory * v2 +

Missing values unsp eci ed, b ottom, ... are widely

1.0 - errorx * errory * v3 +

1.0 - errorx * 1.0 - errory * v4

used in programming language design. As far as

+ 0.5;

we know, however, Envision is the rst language

intout = interpolated_value;

in which they are rst-class ob jects. That is, they

if intout < minval2 intout = minval2;

can be assigned to variables, stored in data struc-

else if intout > maxval2

intout = maxval2;

tures including sheets, and so forth. Basic arith-

array2[newx * ysize2 + newy]

metic op erations have b een extended to handle the

= intout;}}}}}

p ossibility that some of their inputs may b e missing

typically returning a missing value and to return

missing values in other appropriate cases e.g. divi-

Figure 1: C co de to rotate and shift an image array.

sion by zero.

We b elieve that rst-class missing values are an ex-

6 Other new language features

tremely useful feature, which could be used else-

where in high-level languages. For example, they

could serve as the values of symb ols whichhave not

To make full use of sheets, Envision provides a range

yet b een b ound, or as the value of asso c for items

of other new language features.

not in the list.

Missing values also represent a di erent philosophy

6.1 Points

for error handling. Standard languages trigger an

error by default, and optionally let the user install

A new data typ e, the \p oint," is intro duced to rep- error handlers. By default Envision triggers error

resent lo cations in the domain of a sheet and val- breaks much more seldom. The user must force ad-

ues stored in its co domain. Following the standard ditional error breaks by explicitly testing whether

conventions of pure mathematics, a 1D p oint is sim- some condition is satis ed e.g. some value is non-

ply a numb er. Higher dimensional p oints, such as missing. This \mellow" convention is essential for

2D and 3D p oints, are implemented as structures. image pro cessing, in which the failed computation is

typically only one of a million similar computations, The scanner input determines which samples are

most of which probably succeeded. enumerated e.g. every sample? every other sam-

ple? and in which order. Envision includes a selec-

tion of standard scanners, including a default one

6.3 Samples

used if the scanner input is omitted. Programmers

can easily add new ones.

Any lo cation in a continuous sheet can b e accessed,

Scan di ers from the standard Scheme map op era-

but only certain sp eci c lo cations, namely those on

tor in twoways. It enumerates lo cations samples,

the storage grid, can b e set. Envision includes direct

not values. This is essential in image pro cessing,

p ointers to grid lo cations, called \samples." Sam-

where an output value typically dep ends not only

ples allow the programmer to bypass scaling and

on the corresp onding input value but also on values

interp olation of lo cations in a sheet's domain, nec-

near it. Second, scan gives the programmer exible

essary for optimizing certain low-level vision algo-

control of the enumeration order. Such control is

rithms.

more imp ortant in computer vision than in tradi-

tional Scheme applications, b ecause a 2D image can

To do this safely, programmers have no direct ac-

b e ordered in more useful ways than a 1D list can.

cess to the raw array co ordinates stored inside each

sample. Rather, high-level op erations allow them

to nd the sample nearest a oating-p oint lo cation,

retrieve the samples at the two extreme corners of

6.5 Geometrical ob jects

a sheet's fo cus area, nd the scaled co ordinates of

a sample, moveby a sp eci ed displacementonthe

sample grid, and so forth. Because of the restricted

Graphical display is largely handled by a single

direct access, Envision samples are similar to Java's

primitive DRAW. Input to DRAW includes a ge-

\safe p ointers."

ometrical ob ject, a window, a lo cation in the win-

dow, and a list of options e.g. color, lled, size.

6.4 Scanners

The typ e of the geometrical ob ject determines what

sort of gure will b e drawn.

Applying a low-level vision op eration to a sheet typ-

Geometrical ob jects include 2D sheets mapp ed

ically requires enumerating the samples in its fo cus

onto the window, 1D sheets drawn as curves,

area. In traditional computer vision programming,

p oints, line segments, p olygons, ellipses, and text.

the user must extract the array b ounds and com-

The parameters in line segments, p olygons, and el-

p ose a double lo op. In Envision, most enumeration

lipses may b e p oints or 1D sheets. In the latter case,

is done with the high-level primitive SCAN. Explicit

the ob ject represents a set of ob jects if the sheets

lo ops are reserved for algorithms with unusual struc-

are discrete. If they are continuous, the ob ject rep-

ture.

resentsaswept strip or volume. These geometrical

ob jects can also b e used in implementing high-level

Scan has the following syntactic form, in which the

vision algorithms.

test and the scanner are optional:

scan variable sample-or-sheet

6.6 File storage

test scanner

expr1 expr2 ....

Scan enumerates the samples in the fo cus area, Scheme includes only ASCI I le I/O, unsuitable for

binding the variable to each one in turn and evaluat- storage of ob jects as large as sheets. Envision pro-

ing the expressions inside the form. The scan starts vides a second typ e of structured le I/O, in which

at the input sample, or at the rst lo cation in the packed sheet data is written in binary and other ob-

input sheet. When a sample passes the test or the jects are written in a tagged ASCI I representation.

end of the sheet is reached, it halts, returning the Op erations are also provided to read bytes and se-

current sample and a b o olean indicating whether it quences of bytes, for reading other image le for-

ran out of samples. The returned sample allows the mats e.g. PPM, JPEG and communicating with

scan to b e restarted from where it left o . devices e.g. cameras.

6.7 Storage areas, op en les, windows This architecture o ers three advantages. First,

since our primary eld is not programming lan-

guages and we wanted to pro duce a usable proto-

As describ ed ab ove section 2, sheets cannot be

typ e quickly, we simpli ed our work by using an

garbage collected automatically. To help the user

existing Scheme implementation and not mo difying

manage sheet space, Envision maintains a list of

its internals. Second, individual users create new

storage groups, i.e. sets of sheets sharing a common

copro cessor binaries whenever they link in C co de

packed storage area. For each storage area, it can

generated for them by the compiler. It is convenient

provide one representative sheet, which the user can

that they need only rebuild the copro cessor binary,

examine, e.g. when deciding whether to deallo cate

b ecause the Scheme binary is 30 times larger and

it.

more complicated to rebuild. Finally, we wanted

to test how well algorithms could be divided into

Since we are forced to provide storage-management

sheet-pro cessing and high-level parts. A clean algo-

to ols for one badly-b ehaved typ e of data, there is no

rithmic separation would simplify taking advantage

conceptual problem extending such to ols to other

of sp ecialized image pro cessing b oards or a second

places where they would be useful. The ease with

pro cessor, without placing undue strain on the bus

which users can lose p ointers to op en les and win-

or network connecting these to the main pro cessor.

dows is a long-standing problem in high-level lan-

guage design. Envision allows the user to list such

op en connections.

7.2 Variable compilation

Atypical computer vision algorithm contains b oth

7 Our implementation

functions that manipulate the values within sheets

and high-level functions that op erate on more tra-

ditional data structures. Because they manipulate

We have implemented Envision as an extension to

ob jects of grossly di erent size, these twotyp es of

the Scheme48 implementation of Scheme [9]. The

functions require very di erenttyp es of compilation.

overall structure is determined by three main ideas:

It would b e premature to decide whether this is a

separation of sheet data from the high-level front-

binary distinction or two samples from a continuous

end, variable compilation, and separation of sheet

variation.

typ e handling into run-time and compile-time com-

p onents.

High-level scheme functions are compiled into

Scheme48's byte co de by Scheme48's compiler.

They can use all the features of Scheme and Envi-

7.1 Two-pro cessor architecture

sion. However, Scheme functions which use sophis-

ticated features cannot be compiled into co de e-

Wehave implemented Envision using two pro cesses.

cient enough to scan op erations across large sheets,

1

The front-end is Scheme, augmented with a variety

on current hardware.

of functions implementing Envision's user front-end

Functions which scan across sheets must be com-

and its compiler. Sheet data, window graphics, and

piled for maximum eciency. The typ es of all vari-

binary le I/O, however, are handled by a sepa-

ables must be determined at compile time. The

rate C program. This \copro cessor" is connected

user must declare the typ es of input and output

to Scheme via a Unix so cket.

values, b ecause it is frequently imp ossible to infer

Crucially, packed data from sheet storage areas is

whether numb ers and sheets are real/continuous or

never passed down the so cket. To the user, sheet

integer/discrete. An error is triggered if the com-

data app ears to reside in Scheme. In fact, the

piler cannot determine the typ e of anyinternal vari-

packed storage areas for sheets reside in the copro-

able.

cessor. Scheme has only the header data for each

Furthermore, such functions cannot allo cate or del-

sheet, plus a unique identi er that allows it to iden-

lo cate non-stack space, nor can they call graphical

tify the storage area when communicating with the

display functions. Variables are restricted to p oints,

copro cessor. Therefore, the so cket connection do es

b o oleans, sheets, and samples. Only p oints can b e

not have to be fast. In our exp erience, the only

1

interfaces fast enough for image transmission use

They would run faster if compiled into C, e.g. using

shared memory and these tend to b e fragile. Biglo o [15 , 16], but not fast enough.

missing. Only basic control constructs are allowed. 8 The Envision copro cessor

These restrictions were inspired, in part, by those

of Prescheme [9].

The copro cessor provides four capabilities: allo ca-

Previous optimizing Lisp and Scheme compilers,

tion and dello cation of packed storage for sheets, the

such as Biglo o or Franz Common Lisp, regard the

run-time comp onent of sheet supp ort, a stack ma-

input co de as xed and take as their goal optimiz-

chine that can run user-de ned co de, and a graphics

ing it as much as p ossible. The harsh environment

interface with a built-in event lo op.

of image pro cessing forces us to take a di erent at-

titude for sheet-handling co de: the co de must run

8.1 Implementation of sheets

with sucient sp eed and therefore the user must b e

help ed to write such co de, by a combination of lan-

guage restrictions and compiler errors. Computer

Sheets are implemented as arrays of bytes. Dep end-

vision researchers nd it frustrating to guess what

ing on the range and precision requested by the user,

mo di cations to their co de will convince a general-

between one and three bytes are allo cated p er pixel.

purp ose compiler to make it run fast enough.

Missing values are marked by storing a sp ecial re-

served value into the array. Sheets with 2D domain

Envision's compiler pro duces two typ es of output

are implemented using a 1D array of p ointers to the

for sheet-handling functions. For debugging co de

rst elementineachrow, which results in faster ac-

on small images, they can be compiled into co de

cess than standard address arithmetic. Sheets with

that runs on the copro cessor's stack machine sec-

2D or 3D co domain are implemented using twoor

tion 8.2. For nal use, they are compiled into C

three arrays.

co de, which can be linked directly into the copro-

cessor.

With each sheet, the copro cessor stores three acces-

sor functions. These accessors are given raw array

co ordinates: scaling is handled byScheme and the

compiler. Two accessors retrieve and set the value

at a particular integer array lo cation. The third

7.3 Sheet typing

accessor, present only for sheets with continous do-

main, retrieves an interp olated value for a lo cation

sp eci ed by oating p oint co ordinates. All three ac-

cessors handle circularity, missing values, and range

restrictions. However, they return rawinteger val-

Typ e features for sheets and, by extension, sam-

ues, to which the compiler must apply the appro-

ples are divided into two groups. The dimensional-

priate scaling and o set.

ity of the domain and co domain, and whether each

is continuous or discrete, have profound e ects on

Interp olation is implemented using a nine-p oint

algorithm design. Only the most trivial functions

second-order p olynomial interp olate. When all 9

e.g. copy are p olymorphic across these distinc-

values are available, this is similar to the six-p oint

tions. Furthermore, they drastically a ect C co de

interp olate describ ed in [2]. However, our inter-

generation, e.g. whether C variables are declared as

p olation algorithm handles any pattern of missing

oats or ints, whether 1D or 2D co de is substituted

values, handling simple cases quickly and decaying

when expanding a SCAN form, and whether the in-

gracefully to a bilinear, linear, or nearest-neighbor

puts to addition are numb ers or vectors. Therefore,

interp olate as required. This capability is required

these typ e distinctions are resolved at compile-time.

for correct, fully general implementation of op era-

tions such as image rotation. However, it would b e

By contrast, the design of most computer vision al-

very dicult for most users to implement on their

gorithms do es not dep end on the other typ e fea-

own and no previous vision package provides it.

tures: range, precision, circularity, or whether miss-

ing values might b e present. Previous systems typ-

ically forced users to make some of these distinc-

8.2 Running functions

tions at compile-time, resulting in annoyingly non-

general co de e.g. edge nders that would run only

From the Scheme interpreter, the user can call user- on signed 8-bit images. The increase in generality

de ned functions installed in the copro cessor. These obtained by resolving these distinctions at run-time

include fully compiled functions linked directly into is worth the small p enalty in running time.

the copro cessor and also functions compiled, for de- control constructs which threatened to create dif-

bugging, into instructions for the copro cessor's stack culties and which did not seem useful in writing

interpreter. The interpreter includes simple assem- sheet-handling functions which tend to have a re-

bler instructions, a function calling mechanism, sp e- stricted structure. On the other hand, the Envision

cial handlers for basic sheet op erations, and a wide compiler sp ends considerable e ort optimizing the

range of mathematical functions directly available handling of higher-dimensional ob jects and missing

in the standard C library e.g. trignometric func- values.

tions.

9.1 Typ e inference

When some inputs to a function are sheets, the sheet

header information is passed from Scheme to the

copro cessor. Sheet headers are large compared to

Envision's typ e inference engine allows typ es to b e

the other typ es allowed 216 bytes, and it is very

parameterized by dimension. Points have a single

inecient to copy them around C's stack or the co-

dimension parameter 1D, 2D, or 3D. Sheets and

pro cessor's stack. Therefore, sheet headers passed

samples have two dimensions: one for the domain

from Scheme are stored in a sp ecial array and re-

and one for the co domain. This allows typ e in-

ferred to bynumb er. The contents of this array are

ference rules to enforce appropriate dimension rela-

static during the function call, b ecause user-de ned

tions among the inputs to a function, and b etween

copro cessor functions cannot create, delete, or mo d-

the inputs and outputs. It also gives compiler func-

ify sheets.

tions access to the dimensions as numb ers. For ex-

ample, the function which extracts the k th co ordi-

nate of a vector must test whether k is in the correct

8.3 Graphics supp ort

range.

Typ e inference handles missing p oints by assigning

Finally, the copro cessor manages the user's interac-

them a typ e with a sp ecial wildcard value in place

tion with the window system. It includes op erations

of the dimension. These typ es are fused with normal

for creating and destoying windows, and primitives

typ es in the obvious way, e.g. when a missing and a

for displaying graphical ob jects on them. Events

non-missing value are generated by the two branches

such as window resizing, motion, and exp osure

of an if statement.

are handled automatically. Command-typ e mouse

events moving and clicking inside windows will

9.2 Scanner substitution

eventually b e handled by an X-based user-interface

program. The current implementation uses the X

window system but the user-level language is generic

To avoid function calls inside lo ops at run-time,

and should be compatible with many window sys-

the enumeration co de from the sp eci ed scanner is

tems.

substituted into each scan form at compile time.

This substitution pro cess must examine whether the

sheet input is a sheet or sample, and whether it is 1D

or 2D. For example, the default scanner FORWARD

9 The compiler

contains two versions of the lo oping co de, one for

1D sheets and one for 2D sheets. While not concep-

tually complex, typ e-dep endent substitution cannot

The Envision compiler transforms the user-level

b e accomplished with standard Scheme macros and

co de into an intermediate language, with op erations

must therefore b e built into the compiler.

and control structure similar to C, but with Lisp-

like syntax. This transformation is carried out by

Scheme-to-Scheme transformation rules inspired by

9.3 Real numb ers

but rather di erent from those in [8]. From the

intermediate language, it is easy to generate b oth C

It is incredibly inecient to rebuild real-number

co de and co de for the copro cessor's stack machine.

handling, including utilities such as trigonometric

functions and random-number generation, on top With the exception of certain straightforward basic

of integer arithmetic. C provides well-optimized if comp onents, our compiler handles problems largely

not ideally general real numb er handling, whichwe disjoint from those treated by previous compilers

used. e.g. [9, 15, 16]. On the one hand, we excluded

9.4 Missing values stricted macro facilities such as Scheme's de ne-

syntax. Moreover, the prop er expansion dep ends

on the dimensionalities of the inputs and, thus, it

To a rst approximation, a missing value might ap-

must followtyp e inference.

p ear anywhere that a p oint is exp ected. A naive

implementation might incorp orate a test for miss-

Expansion of vector op erations must follow genera-

ing values into the implementation of each sensitive

tion of tests for missing inputs. The vector expan-

op eration, e.g. all the numerical functions. How-

sions destroy groups of strict op erations, b ecause a

ever, this results in massively more testing than is

single user-level op eration may b ecome a complex

p erformed in hand-written co de.

form which sets and uses temp orary variables. A

particularly bad example is the cross-pro duct op era-

The compiler p erforms a \purity analysis" to de-

tion. Therefore, even if a general-purp ose compiler

termine which variables and expressions can never

supp orted missing values, it would still b e dicult

return a missing result. Avalue may never b e miss-

to de ne vector op erations using user-level features

ing b ecause it came directly or indirectly from a

such as macros or classes.

constant input. It might be the result of a strict

2

op erator applied to never-missing values. Certain

op erations for retrieving sheet parameters e.g. the

9.6 Sheet references

o set cannot return missing values. These app ear

in the expansion of extremely common functions,

Op erations which set or access sheet values must

notably those for setting and accessing values in

also be expanded with some care. To a rst ap-

sheets.

proximation, they simply add scaling and o set to

Finally, a value can never be missing if it is pro-

the low-level access function. However, likevector

tected by an explicit test for whether it is missing.

op erations, they must allo cate temp orary variables

Some tests o ccur in the user-level co de. Others are

exactly when needed. Furthermore, if the domain

generated automatically when the compiler expands

and/or co domain is discrete, scaling must b e done

sensitive op erations.

using exact integer op erations whichcheck that the

divisions involved have no remainder. Therefore,

The compiler also recognizes connected groups of

certain parts of this expansion must b e delayed un-

strict functions and collects all required tests for

til after typ e inference has b een done.

missing values at the start of the group. Prior to

this step, the compiler restructures the co de so that

expressions do not contain any forms which might

9.7 Space allo cation

generate side-e ects, so that a left-to-right order of

evaluation is preserved when sub-expressions are ex-

Dynamic storage allo cation is to o slow to b e allowed

tracted.

inside sheet-handling functions. All the non-stack

storage required must b e allo cated b efore the func-

9.5 Vector op erations

tion is called, and passed to it. Therefore, sheet-

handling functions cannot use lists to return several

ob jects and so the compiler must supp ort multiple

Expansion of vector op erations ensures that tem-

return values.

p orary variables are allo cated as needed, but not if

the input is a variable or a constant. Moreover, if an

Points, including numb ers and missing p oints, are

input is explicitly headed bya2Dor3Dpoint con-

represented by C structs. When sucha value is re-

structor or a sequence ending in such a form, the

turned by a form inside a SCAN lo op, it is inecient

input is decomp osed into its constituents at compile-

to create the struct anew in each iteration of the

time rather than at run-time. For example, a se-

lo op even on C's stack. Instead, the compiler re-

quence of 3D vector + and * op erations will b ecome

serves stack space for all suchinternal p oint structs

three 1D numerical expressions followed by only one

once, at the start of the sheet-handling function.

p oint constructor.

When, in addition, an internal p ointvalue is known

This complex analysis of the input, and deconstruc-

never to be missing, the compiler can pre-set the

tion of some inputs, is beyond the power of re-

missing? eld of the p oint struct. Thus, inside a

2

scan lo op, the only elds of the struct whichmust

I.e. an op erator which never returns a missing value when

b e examined or set are the actual numerical values. given non-missing inputs.

This optimization eliminates essentially all overhead 11 Conclusions

on 1D arithmetic involving non-missing numb ers.

Attempting to avoid overhead on simple arithmetic This pap er has shown how techniques of mo dern

is common in compilers for high-level languages. programming language design can be successfully

applied to an unusual domain: computer vision. We

However, it is dicult to do in the context of a

form whichisevaluated only once or a few times have seen that that image handling requires inter-

esting new programming language constructs, in-

each time the function is called. Our optimization

is easy and often applicable, b ecause it exploits the cluding new data typ es sheets, samples, a new

fact that scan lo ops contain many strict arithmetic mapping-typ e op erator scan, and rst-class sup-

p ort for missing values. We have also seen that,

op erations and forms inside scan lo ops are evaluated

many times. although the huge size of images demands extreme

eciency, this can b e achieved by compiling a high-

level language using current metho ds, appropriately

9.8 Linear op erations adapted to the sp eci c application.

Hand-written C co de often takes advantage of the

Acknowledgments

fact that image pro cessing op erations often add or

subtract values from di erent lo cations in the same

image. Weintend, eventually, to detect forms mak-

This research was supp orted by NSF grants IRI-

ing multiple references to the same sheet and factor

9501493, IRI-9420716, and IRI-9209728. Wewould

out the scaling and o set applied when extract val-

also like to thank Richard Kelsey, Jonathan Rees,

ues from the sheet.

Manuel Serrano, and Val Tannen.

References

10 Implementation results

[1] Amerinex Applied Imaging 1996

We are in the late stages of debugging Envision and

\Image Understanding Environment Program:

writing appropriate example co de and new-user do c-

Overview," http:// www.aai.com/ AAI/ IUE/

umentation. Draft do cumentation can b e found on

IUE.html, 9 Septemb er 1996.

our web site [18] and we anticipate releasing the

[2] Bracewell, Ronald N. 1995 Two-Dimensional

co de in early fall. It requires only standard Unix

Imaging, Prentice-Hall, Englewo o d Cli s NJ.

comp onents ANSI C, so ckets, and Xlib and cur-

rently runs on three op erating systems Linux, HP-

[3] Clinger, William, Jonathan Rees, et al. 1991

UX, and SGI Irix. Both Scheme48 and Envision

4

\Revised rep ort on the algorithmic language

are extremely small systems: compressed source for

scheme," ACM Lisp Pointers 4/3, 1{55.

b oth will t on two oppy diskettes.

[4] Fleck, Margaret and Daniel Stevenson, \The

The current system is fast enough for many typ es

Iowa Vision System Pro ject," http://www.

of image pro cessing research. Rotation of a 538 by

cs.uiowa.edu/ ~m eck/ vision-html/ vision-

364 image by an arbitrary angle takes 6 seconds

system.html, 13 Septemb er 1996.

on a 120MHz Pentium PC and under 3 seconds on

an SGI Indigo 2. Functions run on the copro cessor's

[5] Heeger, David and Eero Simoncelli, \OB-

stack machine take ab out 7 times as long: still su-

VIUS," http:// white.stanford.edu/ ~heeger/

ciently fast for debugging using small examples. We

obvius.html, 1 Novemb er 1996.

b elieve that a combination of further optimizations

and rapidly increasing pro cessor sp eed will eventu- [6] Jacot-Descomb es, Alain, Marianne Rupp, and

ally make the output suitable for a wide varietyof Thierry Pun, \Lab oImage: a p ortable window-

image pro cessing applications. The most demand- based environment for research in image pro-

ing real-time applications may, however, require a cessing and analysis," SPIE Proc. Vol 1659:

more sophisticated compiler which can take advan- Image Processing and Interchange: Implemen-

tage of image pro cessing b oards. tation and Systems 1992, pp. 331{340.

[7] \KBVision," Amerinex Applied Imaging Inc.,

Amherst, MA, http:// www.aai.com/ AAI/

KBV/ KBV.html, 1 Novemb er 1996.

[8] Kelsey, Richard and Paul Hudak 1989 \Re-

alistic Compilation by Program Transforma-

tion," Proc. 16th ACM Symp. on Principles of

Programming Languages, pp. 281{292.

[9] Kelsey, Richard and Jonathan Rees 1995 \A

Tractable Scheme Implementation", Lisp and

Symbolic Computation 74.

[10] \Khoros," Khoral Research Inc., Albuquerque,

NM, http:// www.khoros.unm.edu/ khoros/, 1

Novemb er 1996.

[11] Kohl, Charles and Jo e Mundy 1994 \The De-

velopment of the Image Understanding Envi-

ronment," CVPR 94, pp. 443{447.

[12] Landy, Michael S., Yoav Cohen, and George

Sp erling, \HIPS: A Unix-Based Image Pro cess-

ing System," CVGIP 25 1984, pp. 331{347.

[13] Laumann, Oliver and Carsten Bormann 1994

\Elk: the Extension Language Kit," USENIX

Computing Systems 7/4, pp. 419-449.

[14] Pop e, Arthur R. and David G. Lowe, 1994

\Vista: A Software Environment for Computer

Vision Research," CVPR 94, pp. 768{772.

[15] Serrano, M. and Weis, P. 1995 \Biglo o: a

p ortable and optimizing compiler for strict

functional languages," SAS 95, pp. 366{381.

[16] Serrano, M. 1994 Vers une compilation

portable et performante des langages fonction-

nels,Th ese de do ctorat d'universit e, Universit e

Pierre et Marie Curie Paris VI, Paris, France.

[17] SRI International, \RCDC Home Page,"

http:// www.ai.sri.com/ p erception/ software/

rcde.html, 1 Novemb er 1996.

[18] Stevenson, Daniel and Margaret Fleck, \En-

vision: Scheme with Pictures," http://www.

cs.uiowa.edu/ ~m eck/ envision-do cs/ envi-

sion.html, 7 June 1997.

[19] Thompson, Clay M. and Loren Shure 1993-95

\Image Pro cessing To olb ox for use with MAT-

LAB," MathWorks Inc., Natick, MA.

[20] Ullman, Je rey D. 1994 Elements of ML Pro-

gramming, Prentice-Hall, Englewo o d Cli s NJ.