Please consider a donation to the Higher Intellect project. See or the Donate to Higher Intellect page for more info.

ImageVision Library

From Higher Intellect Vintage Wiki
Revision as of 22:31, 1 September 2020 by Netfreak (talk | contribs)
Jump to navigation Jump to search

The ImageVision Library (IL) from Silicon Graphics is an object-oriented, extensible toolkit for creating, processing, and displaying images on all Silicon Graphics workstations. The library provides image processing application developers with a robust framework for managing and manipulating images.

Today's rapidly advancing hardware technology often requires software developers to rewrite their code for each new release. IL is explicitly designed to provide a constant software interface to changing hardware. Applications you write today will run on all future generations of machines, requiring few or no changes. With IL, Silicon Graphics can continue to bring you the benefits of next-generation hardware while giving you all the advantages of a stable but growing software environment.

The latest version of ImageVision Library, version 3.0, offers significant performance and functionality advances over past releases.

New in ImageVision Library 3.0:

  • It is written on OpenGL and IRIX 6.2.
  • It has greatly improved multiprocessor scaling over IL 2.5.
  • It has an ELT (Electronic Light Table) Operator.

· It includes the Imglab interactive graphical image processing toolkit for rapid prototyping.

· Its file handling abilities have been enhanced with the addition of the Image Format Library (IFL) providing support for opening, reading, writing and creating image files in a format independent manner.

Figure 1 depicts the software interface layers available to programmers writing imaging applications on SGI hardware and ImageVision's position among them.

FIGURE 1 Image Processing application interfaces on SGI hardware

Fig 78.gif

1.1 Abstract

IL consists of a library developed in C++. An interfaces for C programmers is included in a supporting library.

The current release of IL contains a core set of more than eighty image processing functions common to most disciplines; more will continue to be added in future releases. Since developers must work with such a broad range of image processing operators, IL has been designed to allow you to extend this set to suit your specific needs. Silicon Graphics provides a set of data abstractions and access functions that make it easy to augment IL's image operators and design new ones.

Similarly, image data sets come in a bewildering variety of formats. IL uses the Image Format Library (IFL) to accommodate developers' needs by allowing new file formats to be integrated seamlessly into the library.

IL provides an efficient model for the manipulation of image data and image attributes. IL's image model includes a configurable cache to allow access to and processing of the very large images common in many disciplines. It provides a common interface for image manipulations, while requiring little or no programmer knowledge of the image's internal structure or format.

In addition, IL supports the ability to chain a series of image operations together. The chained operations are then executed on demand, processing data from the requested area only. Furthermore, no intermediate results need to be stored between each step in the chain. IL's demand-driven execution model, in conjunction with its ability to chain operators, provides a powerful environment for building image processing applications.

IL's execution model also employs the full power of the hardware. IL transparently supports the parallel processing and graphics features of Silicon Graphics workstations. The multi-threaded implementation of IL allows single-processor platforms to perform look-ahead operations. On multi-processor architectures, IL further utilizes multi-threading to execute processing requests automatically in parallel.

In summary, Silicon Graphics's IL provides the following features:

  • · an image processing programmer interface common across all Silicon Graphics workstations
  • · a core set of general-purpose image operators and an easy way to add new ones
  • · a framework for chaining a sequence of operators together
  • · an efficient method of augmenting the set of supported image file formats
  • · an optimized memory model for handling very large images
  • · an efficient method for pre-fetching image data
  • · transparent support for execution on single processors and multiple, parallel processors<
  • · an architecture that supports general image types

1.2 Overview

IL organizes the diverse I/O, computation, and display requirements of an image processing application into a set of coordinated programming models. These models are outlined in the following sections.

1.2.1 Image Object Model

The foundation and unifying concept of IL is the image object. All image types are derived from a common object definition. These image types include:

  • · a memory image, implemented as a contiguous array
  • · a cached image that resides in a file and is buffered in memory
  • · a displayed image, resident in the frame buffer
  • · an operator image that implements an image processing algorithm

By sharing common mechanisms for manipulating data and attributes, all image types can be handled in a consistent fashion. This results in a streamlined programming model that greatly simplifies application development.

1.2.2 File I/O Model

The file I/O model abstracts how images are accessed from disk. File images use a look-ahead buffer or cache to minimize delays caused by disk I/O. The common object definition allows an application to transparently support the different file formats provided by the Image Format Library (IFL). You can easily integrate new file formats into IFL without modifying the application.

1.2.3 Execution Model

IL implements a pull-driven, or demand-driven, model, such that data is processed only on demand.

FIGURE 2 Push Execution Model versus ImageVision Library

Fig 58.gif

The model is based on the same cached-image model as file images. This technique enables an application to process just the area of interest providing significant benefits in terms of reduced I/O and improved system performance. The pull execution model also enables IL to efficiently support chaining or linking of image processing operators. This allows a sequence of operations to be performed on a subregion without creating temporary images to hold intermediate results.

In contrast, traditional, or push execution models require that each image operator process the entire image in sequence and also require extra buffers to store the intermediate results. Figure 2 contrasts the push and pull execution models.

1.2.4 Display Model

The display model defines how images are displayed on the screen. It provides an abstraction of an X window and can display one or more images in subregions of the window, called views (shown in Figure 3). The display model provides methods to move, resize, reorder, and select views to be operated on by display operators such as split, wipe, and translate. This model allows the application to conveniently specify how images are to be displayed while automatically drawing only the portions of each image that are exposed.

FIGURE 3 An Example Using the ImageVision Library Display Model.

Fig 61.gif

1.3 Image Abstraction

IL is based on a single object abstraction of the way in which images are manipulated, ilImage. This abstraction presents a common interface for manipulating images while hiding the actual data representation. The interface provides functions for setting and retrieving information about image size (rows, columns, depth), components or channels, data type, and color interpretation.

Most importantly, ilImage provides a common interface for storing and retrieving image data. These image data-access functions are used to store and retrieve an arbitrary subset of the components for an arbitrary rectangle or tile of pixels. Convenience methods allow access to a single pixel value.

Figure 4 depicts IL abstractions for a set of distinct image types: memory images, disk file images, displayed images, and processed images (operator images).

FIGURE 4 Image Object Abstraction Hierarchy

Fig 1.gif

Because all image types share a common model, a programmer need only access images and image data as an ilImage type. The following sections fully describe the attributes and access methods for all image types.

1.3.1 Data Dimensions

IL supports three main image dimensions: x-dimension or number of columns,
y-dimension or number of rows, and z-dimension or image depth.

Each element in this array, pixel or voxel, can consist of multiple components or channels. All pixels in a given image must have the same number of components and the same scalar data type. There is no prescribed limit to the size of the x, y, z, or component dimensions.

1.3.2 Data Types

Each component of a pixel has a scalar data type that can have one of the following values (using the standard C interpretation): <unknown 0>

  • · bit
  • · char (signed or unsigned)
  • · short (signed or unsigned)
  • · long (signed or unsigned)
  • · float
  • · double

1.3.3 Data Ordering

To provide flexible support for different image formats, IL supports image data ordering as a configurable image attribute. Image data can be retrieved or archived in one of three orders:

1. Interleaved ordering clusters the pixel components together. For example, a three-component (RGB) image would be stored as RGBRGBRGB... and so on.

2. Sequential ordering clusters the individual pixel components on a per-line basis. In the RGB image example above, a corresponding tile of data would contain a line's worth of red values followed by the same line's green values and then the blue values for that line, before continuing with the data for the next line.

3. Separate ordering stores each component in a separate contiguous piece.

1.3.4 Data Interpretation

Image data can be interpreted using several different color semantics. The programmer can define or query an image's color model and, if relevant, its color map. IL supports the following color models: <unknown 0>

  • · luminance
  • · negative (minimum value white)
  • · luminance plus &alpha; (transparency value)
  • · color palette or pseudo-color
  • · RGB
  • · RGB plus &alpha; (transparency value)
  • · HSV (hue, color, and value)
  • · YCC
  • · CMY
  • · CMYK
  • · multi-spectral

1.3.5 Data Access

IL provides access functions for reading and writing image data. Data can be read or written as a rectangular region (tile) or as an individual pixel. A tile can have an arbitrary size and need not match the underlying storage format of the image being accessed. Image data can be accessed in a data type and ordering independent from that of its source; IL performs the necessary conversion.

Programmers sometimes need to work with an irregular shaped region of an image. IL provides an abstraction for defining and applying a mask or region of interest (ROI) to images, ilRoi. This allows operations to be applied to an arbitrarily shaped region of an image using the ilCombineImg and ilRoiImg operators. <unknown 0>

Section 2 Using the ImageVision Library

Using IL is easy. With image objects, it is possible to write many effective, versatile applications. IL allows you to read from multiple sources, construct both simple and complex chains of operators, and write the results to a display or file. In addition, you can interactively modify operator parameters while simultaneously displaying results.

IL represents image processing functions as image operator objects. Each image operator specializes in processing one or more images using a particular algorithm, while allowing user access to the resulting image data through a common programming interface. All image data can be stored or retrieved using IL's setTile, copyTile or getTile functions. Additionally, IL transparently supports the ability to chain image operators together.

Figure 5 shows how elements of an IL application might be connected. IL manages the data caching to appropriately process images from anywhere in the chain.

FIGURE 5 Elements of an IL Application

Fig 14.gif

2.1 Programming with ImageVision

Programming with IL is easy and intuitive. For example, the following simple steps allow you to obtain an image from a file, sharpen it, and write the result back to disk:

1. Open the input image file 
2. Construct a sharpen operator image using this file as input
3. Create the output image file
4. Copy the sharpen image to the output image file

Even better, the following C++ code shows how each of the outlined steps maps easily into a single call to the IL:

void main () {
   // Step 1. Open the input image file
   ilFileImg inimg("image.tif");
   // Step 2. Construct a sharpen operator image using
   // this file as input, sharpen the image by .5
   ilSharpenImg sharpen(&inimg, .5);
   // Step 3. Create the output image file, use the file attributes
   // from the sharpened result.
   ilFileImg outimg("output.tif", &sharpen);
   // Step 4. Copy the sharpened image to the fileoutimg.copy(&sharpen);
   // The IL will flush buffers and close the file automatically
   // when outimg is destroyed

2.2 Making a Simple Chain

Image application developers must often perform more than one operation in sequence. In the following example, the input image is scaled, rotated, sharpened, and then radiometrically adjusted using a look-up table. Here is the new sequence:

1. Open the input image file
2. Construct a scale and rotate operator image using the input image file as input
3. Construct a sharpen image using the warp image as input
4. Construct a piecwise linear mapping operator using the sharpen image as input
5. Create the output image file
6. Copy the piecewise image to the output image file

IL treats all image operators as images, so operators can be given as inputs to other image operators. The ability to specify image operators as inputs enables IL to manage a sequence of operations as a chain transparently. Developing a simple or complex chain in the IL can be as easy as performing single operations. The next C++ code fragment demonstrates the versatility of IL:

  // Step 1. Open the input image file
  ilFileImg inimg("input.tif");
  // Step 2. Construct a scale & rotate operator, rotate by 30
  // degrees and scale it by 0.5 using bilinear resampling
  ilRotZoomImg rotate(&inimg, 30, .5, .5, ilBiLinear);
  // Step 3. Construct a sharpen operator,
  // sharpen the rotated image by .5
  ilSharpenImg sharpen(&rotate, .5);
  // Step 4. Construct a look-up operator, using a piecewise
  // linear mapping
  iflXYfloat bkpts[3] = { iflXYfloat(0, 0), iflXYfloat(100, 60), 
  iflXYfloat(255, 255) };
  ilPiecewiseImg piecewise(&sharpen, bkpts, 3);
  // Step 5. Create the output image file, use the file attributes
  // from the final operator result. 
  ilFileImg outimg("output.tif", &piecewise);
  // Step 6. Copy the final image to the file

2.3 Displaying the Results

Using IL, you can display your results as easily as writing them to an image file. To display your results directly, replace steps 5 and 6 above with the following sequence:

5. Create a display object
6. Invoke a standard event loop

IL provides an efficient model for displaying one to many images within a window. Image rendering with IL uses the X window system and OpenGLTM: // Step 5. create a window to display the image results,

<tt>// save the window id to pass onto IL</tt><tt> </tt>
<tt>Display* dpy = XOpenDisplay(NULL);</tt><tt> </tt>
<tt>ilViewer viewer(dpy, piecewise.getWidth(), </tt><tt> </tt><tt> </tt>
<tt>piecewise.getHeight());</tt><tt> </tt>
<tt>viewer.addView(&piecewise);</tt><tt> </tt>
<tt>// Step 6. process X events</tt><tt> </tt>
<tt>viewer.eventLoop();</tt><tt> </tt>

This code fragment merely shows you the minimal set of features provided by IL. The IL display capabilities also include operations such as roam, wipe, and translate.

2.4 Interactively Modifying a Chain

IL allows you to change the parameters of an existing chain. For example, to alter the sharpness of the image created by the rotate and scale operator in the previous example, you would need to write you own event loop and in response to some user input (like pressing the arrow keys) you would take the following steps: 6. Write a simple event loop

7. Call the sharpen operator's built-in method to alter its sharpness</unknown> <unknown 0>
8. Invoke the re-paint display operator</unknown><unknown 0>

// Step 6. simplified event loop</unknown><unknown 0>
XEvent e;</unknown><unknown 0>
XNextEvent(dpy, &e);</unknown><unknown 0>
switch (e.type) {</unknown><unknown 0>
case KeyPress:</unknown><unknown 0>
   switch(XLookupKeysym(&e.xkey, 0)) {</unknown><unknown 0>
     case XK_Right:</unknown><unknown 0>
        // Step 7. increase the sharpness 
        sharpen.setSharpness(sharpen.getSharpness()+.1);</unknown><unknown 0> 
        // Step 8. repaint the result</unknown><unknown 0> 
        viewer.paint();</unknown><unknown 0>
        break;</unknown><unknown 0>
</unknown><unknown 0>
    break;</unknown><unknown 0>
default:</unknown><unknown 0>
    // let the viewer handle the remaining events</unknown><unknown 0>
    viewer.event(&e);</unknown><unknown 0>
    break;</unknown><unknown 0>

You can perform similar steps to adjust each image operator's values as shown in <a href="index.html#REF35159">Figure 6</a>. <unknown 0>

<a name="REF35159"><paranum></a>FIGURE 6 Interaction Within an ImageVision Application</unknown>

<a href="fig/"><img src="/web/19970727074634im_/" width="517" height="268" sgi_src="/d/roots/godot/ilweb/techreport/fig/fig_29.gif"></a>

<unknown 0>

2.5 Constructing a Complex Chain</unknown>

Chains do not have to be linear. Individual operators can fork to several operator chains. In the previous example, the results of the sharpen operation can be routed into one display view while the results of the LUT operation can be directed to a second view. The split display operator can then be used to compare the two outputs. <unknown 0>

2.6 Interfacing to User Interfaces</unknown>

IL is independent of the User Interface (UI) and therefore can be used with any UI toolkit. IL operators provide public member functions that make them easy to control interactively. When these attributes are altered, any cached data in the operator image is discarded. In this way, an operator can have its behavior modified without having to be destroyed and re-created. When an image in the chain is affected by parameter modifications, the succeeding images are informed that their results must be updated.

IL can be controlled with keyboard input, mouse position, Motif widgets, or any combination of these or any other toolkits. For example, ilCompassImg performs directional edge enhancement. IL provides member functions to specify the direction as an x-weight and y-weight, a floating-point angle, or a predefined direction such as north or south-west. Mouse position could be used to control the
x-weight and y-weight. The direction could also be specified as an angle from the keyboard, or it could be selected by providing Motif push buttons labeled North, South, East, and West. This simple yet flexible control makes it easy to develop interactive image processing applications.

In addition to standard image processing operations, IL provides display operators such as roam, wipe and split view. Again, any combination of UI widgets can be used. For example, mouse position could be used to control roaming through a large image. Alternatively, a Motif scroll-bar could be used to control the wipe between two images being compared.

For example, when using a Motif scroll-bar, the callback routine for a "value changed" event could determine the new position of the scroll bar and then use this information to set the zoom factor on ilRotZoomImg. Similarly, the callback routine for a Motif push button labeled "2:1" could set the zoom factor to 2 on ilRotZoomImg. These two widgets, used together, provide the ability to step to a desired zoom factor and then zoom interactively relative to the current zoom setting.

The X event queue can deliver mouse-position events, mouse-button events, or keyboard events. To control roaming with the mouse, you can use the ButtonPress, MotionNotify and ButtonRelease events to specify the delta-x and delta-y for the translate operator. <unknown 0>

2.6.1 Integration with ViewKit and RapidApp</unknown>

ImageVision Library 3.0 is integrated with ViewKit and RapidApp. A separate library is provided that includes about a dozen ViewKit components including: <unknown 0>ilVkWindow a very easy to use image viewer derived from VkWindow with built in menus to allow images to be opened and simple view manipulation.</unknown><unknown 0>ilVkViewer just the viewer component without the menus, derived from VkComponent</unknown><unknown 0>ilVkHistGraph an interactive histogram viewer</unknown><unknown 0>ilVkDetailView a viewer for extracting quantitative information about an image's pixels.</unknown><unknown 0>ilVkRotZoomView a viewer with built in rotate and zoom capability</unknown>

All of these components are available from a RapidApp component palette and can be used to quickly construct a user interface for an interactive IL based application. <unknown 0>

Section 3 Architecture</unknown>

IL's fundamental building blocks include its caching mechanism, broad variety of image operators, efficient execution model, multiple file types, and versatile techniques for displaying results. <unknown 0>

3.1 Caching</unknown>

Data movement can be a critical bottleneck in the implementation of an image processing library. To avoid this bottleneck, IL processes data in pieces small enough to fit in working memory. If every data request were serviced directly from the disk, performance would suffer, since the computation would need to wait for each new piece of data to be read or written. To avoid delays caused by disk I/O and re-computation, the data read from disk and the processed results in memory must be cached.

The cache holds two different types of image data. <unknown 0>

1. When reading image files from disk, the cache stores raw, or uncompressed, data. If the image is stored by rows, the cache will be allocated by rows matching those in the file. If it is stored in rectangular chunks, the cache will be allocated in pieces that are the same size and shape.</unknown><unknown 0>

2. For operator images, the cache stores the processed results.</unknown>

The cache stores the image data in fixed-size rectangles called pages. Image pages play a similar role to "traditional" pages in a virtual memory system. The most important difference is the two-dimensional or array-like structure of an image page. This allows for very efficient image oriented memory management. <unknown 0>

<a name="REF92553"><paranum></a>FIGURE 7 Image Storage Model</unknown>

<a href="fig/"><img src="/web/19970727074634im_/" width="217" height="172" sgi_src="/d/roots/godot/ilweb/techreport/fig/fig_38.gif"></a>

Arbitrary reference to image data is provided through tiles. The image access methods getTile and setTile allow access to any contiguous rectangle of image data, as shown in <a href="index.html#REF92553">Figure 7</a>. Because these accesses often do not match the underlying storage format of the image file, the cached image object provides any necessary reformatting of image data.

The cache supports two fundamental data orders: interleaved/sequential and separate. With interleaved or sequential data, all components of a given pixel are stored adjacently; each page therefore holds all components for that page's rectangular area. With separate data, each component is stored separately; there is a separate page for each component in a given page's rectangular area. As with data-type conversion, IL defers page reformatting until it performs each individual access, and the data in the cache is stored in the raw page format of the underlying image file.

If getTile requests a single component and the image file is stored in a separate format, only the pages containing that component will be accessed. For multi-spectral operations, this can result in significantly reduced I/O overhead. The format of choice for multi-spectral image data, therefore, is separate components. Similarly, color data is usually stored interleaved, because all components are accessed together, and the interleaved format matches the storage in the frame buffer. In many cases, this data order eliminates the need to reformat during display operations.

In addition to enabling IL to access a specific set of data, tiling allows it to break up that set into multiple requests. This feature has the dual benefit of allowing data to be manipulated more efficiently in memory and permitting the requests to be distributed to all available processors. <unknown 0>

3.1.1 Avoiding Heap Memory Fragmentation</unknown>

Because images can have widely varying page sizes, the allocation of memory for the image cache can present problems with fragmentation of heap memory. To avoid this problem, IL uses a sophisticated memory allocation scheme that controls fragmentation. Allocated memory is broken up into pools, one for each active page size. Each pool is maintained in its own address region to avoid interactions between different page sizes. Within a pool, compaction of holes in the allocated memory is straightforward since all of the allocations are the same size. When large amounts of memory are freed in a given pool, the memory is returned to the operating system for use by other applications. The IL automatically performs this compaction and reclamation whenever the fragmentations exceed a user-controllable threshold. <unknown 0>

3.2 Operators</unknown>

Operators implement image processing algorithms. They are the building blocks of IL's execution model. IL includes over 80 functions, which are listed in Appendix <a href="index.html#REF24554">A</a> of this report. Future releases will provide additional functionality. Users may easily extend the available set of operators to encompass special needs as described in Section <a href="index.html#REF24309">4.2</a>. Current IL operators include the following: <unknown 0>

  • · color conversion</unknown><unknown 0>
  • · arithmetic functions</unknown><unknown 0>
  • · radiometric transforms</unknown><unknown 0>
  • · geometric transforms</unknown><unknown 0>
  • · statistics</unknown><unknown 0>
  • · non-spatial domain transforms</unknown><unknown 0>
  • · spatial domain transforms</unknown><unknown 0>
  • · edge, line, and spot-detection</unknown>

Operator images extend the object-oriented ilImage to the actual image processing algorithms. The operator image is a read-only image that contains the result of the image processing operation it performs. Operator images can be used as an input to another operator image, an ilFileImg object, or to an ilDisplay object. Since IL also provides a unified programming model, several operator images can also be chained together to execute a sequence of operations.

The operator image is a simple model. As shown in <a href="#Fig8">Figure 8</a>, when the image is accessed with getTile, the cache is searched. If the requested tile does not exist in the cache, an image page fault occurs. The resulting call to get the missing page causes the input data to be requested from the input image with getTile. The returned data is processed as specified by the operator image and the resulting page is stored in the cache. Using this technique, an operator image only processes the part of the image necessary to provide the requested tile. <unknown 0>

<a name="Fig8"><paranum></a>FIGURE 8 Operator Image Data Flow</unknown>

<a href="fig/"><img src="/web/19970727074634im_/" width="471" height="205" sgi_src="/d/roots/godot/ilweb/techreport/fig/fig_40.gif"></a>

The data in the operator image's cache is simply discarded when the page-replacement algorithm is invoked. Unlike file-based image classes, no backing store is required to hold the complete processed image. To prevent data from being recomputed, the cache must be large enough so that overlapping fetches do not read pages that have already been discarded. To save the result of an operation, an image of an appropriate type (for example, ilFileImg) must be created and the operator image copied to it.

The potentially increased memory requirements associated with a larger image cache are offset by this model's reduced number of in-memory data shuffles and its minimized I/O overhead, both of which significantly boost operator performance.

Because operators of varying data types may access image data in the cache, that data is cached in its raw data type (after being decompressed, if necessary). Individual data accesses can explicitly recast it into a more desirable working data type. If an operator is performed predominately on a particular data type, you can code that case to prevent the data from being converted to another type.

Upon creation, operator images define their input images(s) and control parameters. Although control parameters are normally supplied at construction time, IL also provides methods to change these control parameters after the image-operation is created. By default, operator images inherit many attributes from their input image(s), such as data type, image size, and page size; methods to change these attributes are also provided by IL. When these attributes or control parameters are altered, any cached data in the operator image is discarded. In this way, an operator can have its behavior modified without it having to be destroyed and re-created. <unknown 0>

3.3 Execution Model</unknown>

IL implements a pull execution model of image processing in which data is processed only on demand. Relative to push execution and virtual memory models, a pull execution model: <unknown 0>

  • · eliminates the need to read and process excess data</unknown><unknown 0>
  • · obviates need for users to manage the results of intermediate processing</unknown><unknown 0>
  • · decreases the start-up time normally associated with roaming on a large image</unknown><unknown 0>
  • · provides an excellent foundation for parallel processing architectures</unknown><unknown 0>
  • · reduces I/O and memory overhead</unknown><unknown 0>

<a name="REF29635"><paranum></a>FIGURE 9 Execution Model</unknown>

<a href="fig/"><img src="/web/19970727074634im_/" width="539" height="458" sgi_src="/d/roots/godot/ilweb/techreport/fig/fig_46.gif"></a>

<a name="REF99370">Typically, more than one image operator must be applied in order to produce a final image. These operators are implicitly chained together by IL's execution model. Because images can be applied to many image operators and the latter can require multiple input sources, IL supports multiple forward and backward linking. When an image in the chain is affected by parameter modifications, the succeeding images are informed that their results must be updated. </a><a href="index.html#REF29635">Figure 9</a> illustrates the execution model.

The actual chaining is done implicitly as operator images are created. In <a href="index.html#REF29635">Figure 9</a>, for example, a link is established between an ilFileImg and an ilRotZoomImg during the creation of the ilRotZoomImg. Specifically, the ilRotZoomImg becomes a child of the ilFileImg and the ilFileImg becomes the parent of the ilRotZoomImg. IL provides support for chaining multiple parents and multiple children to an image, and ilImage also supports the management of children and parent relations. <unknown 0>

3.3.1 Benefits of the Execution Model</unknown>

A conventional operator execution model would read the input image into a buffer, process the data, then write the result to an output image. IL's operator image model effectively eliminates the need to write out the contents of the buffer by allowing the data to be processed directly into the image cache.

In the case of a single operator that writes its result directly to a file-based image, an operator-image model provides little benefit because data must still be copied to the output image. However, when operations are chained together, each operator in the chain eliminates the requirement for another buffer move.

A chain of operations on a large image (larger than can be cached in memory) using the conventional operator model would require each intermediate stage to be flushed to disk and read back in for the next stage. In the pull model of chained operator images, no intermediate files are generated. Instead, the data for a piece of the final image is pulled all the way through the chain and --- provided the caches are large enough to handle overlaps --- will only be computed once for any given area of any operator image in the chain. Thus the pull execution model completely eliminates
I/O overhead for intermediate processing steps, regardless of an image's size.

Another advantage of this model becomes apparent when roaming on a large operator image. Because only the portion being viewed must be processed, start-up time is significantly reduced. Those portions of the image that are not visited need never be processed at all.

IL's demand-driven, page-oriented execution model leads to a natural coarse-grained parallel processing implementation. IL executes multiple page requests simultaneously on multi-processor platforms. When a copyTile involves multiple pages, the latter are processed by separate threads of execution running on separate processors. The library thus takes advantage of parallel processing without requiring any recoding of page processing methods written for user-defined operators. Existing applications thus become "parallelized" without having to be modified in any way. A further benefit of the multi-threaded extension is the capability to perform look-ahead I/O, both automatically and under explicit control using methods like qGetTile and qCopyTile. <unknown 0>

3.4 File Access</unknown>

ImageVision Library uses the Image Format Library (IFL) to accomplish all image input and output (I/O). IFL provides an abstraction of low level image I/O that lets users write applications without dealing with the details of the image file formats that are being used. It is not even necessary to know what image file format is being used (though IFL does provide facilities for determining the format of an image and accessing special features which are not part of IFL's image I/O abstraction). <unknown 0>

3.4.1 Image File Abstract</unknown>

ImageVision Library provides access to images on disk via the ilFileImg class which can be used as part of an image chain; this object is IL's interface to IFL. ilFileImg abstracts the concept of disk media as an I/O source for accessing or storing image data. ilFileImg is a descendant of ilImage and thus inherits the external interface used for depicting image data on disks. To fully support large images and allow for image data pre-fetching, the ilFileImg abstract is derived from IL's in-memory model, ilMemCacheImg, and thus inherits the features of the cache image. <unknown 0>

3.5 Supported Image File Formats</unknown>

ImageVision provides access to images stored in various formats via IFL. The following sections describe the image formats supported by ImageVision Library 3.0. <unknown 0>

3.5.1 TIFF</unknown>

TIFF is a tag-based image file format introduced by Aldus and Microsoft . The current release of TIFF, Version 6.0, provides support for storing one or more images in a file. This extensible image file format currently provides support for storing images using Lempel-Ziv, CCITT Group 3 or 4 Facsimile, packbits, JPEG or no compression schemes. For further details of TIFF intrinsics, refer to the TIFF Developer's Toolkit (Version 5.0) or the TIFF 6.0 Draft manuals published by Aldus. IL fully supports the TIFF file format, and newly created images default to TIFF.

IL also employs some TIFF 6.0 extensions to provide support for tiled images and various TIFF data types. It extends the TIFF format to support the full range of IL data types better and to allow both temporal and 3D images. <unknown 0>

3.5.2 GIF</unknown>

GIF is the Compuserve Graphics Image File format. It is commonly used on computer bulletin boards. It is essentially a color-index format with a simple compression scheme. It thus store files in a reduced space, with some degradation of image quality. GIF does not support paging. <unknown 0>

3.5.3 PNG</unknown>

PNG implements the PNG file format using version 0.88 of the Portable Network Graphics library, libpng, and version 1.0 of the ZIP deflate/inflate compression library, libzlib. These libraries and their standard headers, png.h, pngconf.h, zlib.h, and zconf.h, are installed as part of IFL. <unknown 0>

3.5.4 JFIF (JPEG)</unknown>

JFIF implements the JFIF File format using the JPEG library, libjpeg, made available by the Independent JPEG Group. In addition to providing the IFL image I/O abstraction, the entire JPEG library is provided ``as is for use by software that has been developed for use with libjpeg. Version 6, 2-Aug-95 of the Independent JPEG Group's compression library, libjpeg, and its standard headers, jconfig.h, jpeglib.h, jmorecfg.h, and jerror.h, are installed as part of IFL. <unknown 0>

3.5.5 Photo CD</unknown>

The PCD file format supports image files produced by the Kodak Photo CD system. Photo CD establishes a system for storing high-resolution digital photographic images on compact discs. The Kodak Photo CD\xaa system: <unknown 0>

  • · scans photographic film</unknown><unknown 0>
  • · processes the resultant images (color correction, color encoding, hierarchical decomposition, and compression) </unknown><unknown 0>
  • · records these images as a series of digitally coded images on a Kodak Photo CD disc</unknown>

In addition to digital images, Kodak Photo CD can produce digital audio data and playback control data. However, IFL only handles the image data files from a Photo CD disc. <unknown 0>

3.5.6 PPM/PGM/PBM</unknown>

PPM, PGM, and PBM implement the PPM, PGM, and PBM file formats using release 7, December 1993 of the NETPBM libraries, libppm, libpgm, and libpbm. These libraries and their standard headers, ppm.h, pgm.h, and pbm.h, are installed as part of IFL. <unknown 0>

3.5.7 SGI</unknown>

SGI file format is a simple file format created by Paul Haeberli and used to store RGB or color-indexed image data. The SGI file format supports run-length encoding and verbatim (no encoding) modes. SGI image pixel data is always composed of one or three bands; the three bands are always interpreted as RGB. <unknown 0>

3.5.8 Raw</unknown>

The iflRaw image file format accesses raw image data stored in a file. The data must be organized in raster fashion. If the data is in pages, the pages must be a fixed size (with partial pages at the image edge padded to fill out the fixed size) and the pages must be ordered in a raster fashion.

The iflRaw format supports the full flexibility of the IFL model: all data types, color models, orders, orientations and page sizes are supported. Like all file formats supported by IFL, you access raw images via the generic object class (or the ilFileImg object for IL users). <unknown 0>

3.5.9 FIT</unknown>

The FIT file format is a simple, tiled format developed during the initial release of IL. You might use FIT as a starting point for defining your own file format.

FIT supports the full flexibility of the IL model: all data types, orders, and page sizes. It uses a default page size of 128 x 128. FIT allows you to reserve space to hold user extensions to the file format. FIT is the only supported format that allows paging in the component dimension which is useful for multispectral imagery. <unknown 0>

3.5.10 ilTCL</unknown>

The ilTCL file format allows you to embed an operator chain in a file using a TCL-based scripting language the is implemented by the imgtcl utility. That file can then be treated like any other image file. <unknown 0>

3.5.11 Tiled Images</unknown>

Tiled image files are supported by TIFF. Some tags have been added and/or extended to store the number of components and the size of the Z dimension.

In addition, IL supports the FIT tiled file format. This format supports the full range of IL capabilities and is intended primarily as an example. The source code for this format is supplied as a basis for implementing user-defined file formats.

Tiling provides many benefits to an image processing application in which you will roam through a large image. Most significantly, tiled images allow you to avoid unnecessary disk I/O by requesting flexible, rectangular memory pages. The immediate results are reduced memory overhead and processing time and maximized application throughput. <unknown 0>

3.6 Display</unknown>

IL's display capability plays an important role in the creation of an interactive image processing application. <unknown 0>

3.6.1 ilDisplay</unknown>

An ilDisplay object defines what will be displayed in an X window. It manages a set of ilViews and provides methods to manipulate the set. When an ilImage is added, an ilView is created for it and added to the set. An existing ilView can be resized, moved, or deleted from the set.

The available ilDisplay methods include: <unknown 0>push/pop Changes the stacking order of the selected views.</unknown> <unknown 0>setBorders Draws or erases borders on the selected views.</unknown> <unknown 0>findView Determines the view visible at a given location on the window.</unknown> <unknown 0>redraw Redraws the window.</unknown> <unknown 0>display Sets the size and position of an ilView.</unknown> <unknown 0>split Displays a split view of active ilViews. It modifies each ilView to accommodate the needs of the split view, using a default window partition method.</unknown> <unknown 0>align Allows views to be aligned to one another. Options are provided for left, right, top, bottom, and center alignment.</unknown> <unknown 0>wipe Performs a wipe of any combination of view edges, using the selected ilViews, and updates the ilViews accordingly.</unknown> <unknown 0>moveView Shifts the position of an ilView on the window by the desired amount in x and y.</unknown> <unknown 0>moveImg Shifts all the images in the selected ilViews by the desired amount in x and y, and updates the corresponding ilViews.</unknown> <unknown 0>update Allows the view size, view position, and image position in an ilView to be updated in one call.</unknown> <unknown 0>

3.6.2 ilView</unknown>

An ilView is an object that associates an ilImage with a rectangular sub-area of a window, called a view. The ilView also defines what position in the ilImage is mapped to the origin of the view. Many of the methods of ilDisplay are also defined on ilVIew as a convenience (such as wipe, moveView, moveImg, update, and so on.) <unknown 0>

3.7 Graphics Hardware Acceleration</unknown>

When displaying on Silicon Graphics platforms, IL automatically takes advantage of the graphics hardware features that can accelerate the requested operations. The operations supported on the available graphics options are shown in <a href="index.html#REF43939">Table 1</a>.

The InfiniteReality\xaa and Impact graphics subsystems include special support (p-buffers) that allows operator chains requiring multiple passes through the graphics pipeline to be accelerated. An auxiliary buffer is allocated in the frame buffer by IL to hold intermediate results between passes. This buffer is independent of the windowing system, so results are not affected by partially obscured windows or edge effects on neighborhood operations. This buffer also allows processing chains that do not end in a displayed result to be accelerated and read back to the CPU.

Graphics hardware support is integrated transparently to the application program. <unknown 0>

<a name="REF43939"><paranum></a>TABLE 1 Supported Hardware Acceleration by Graphics Platform</unknown>

<a href="fig/"><img src="/web/19970727074634im_/" width="469" height="331" sgi_src="/d/roots/godot/ilweb/techreport/fig/tbl_85.gif"></a> <unknown 0>

Notes: <unknown 0>

1. Nearest neighbor resampling only</unknown><unknown 0>

2. Nearest neighbor or bilinear with perspective (bicubic resampling on InfiniteReality)</unknown><unknown 0>

3. 3x3, 5x5, 7x7 general and separable convolution kernels</unknown><unknown 0>

3.8 Multiprocessor Scaling</unknown>

ImageVision automatically executes processing requests in parallel on multi-processor systems. This can greatly speed the processing of large images as shown in <a href="index.html#REF41599">Figure 10</a> below. In addition, ImageVision supports asynchronous operation and process termination. <unknown 0>

<a name="REF41599"><paranum></a>FIGURE 10 Multiprocessor performance scaling with ImageVision</unknown>

<a href="fig/"><img src="/web/19970727074634im_/" width="424" height="245" sgi_src="/d/roots/godot/ilweb/techreport/fig/fig_80.gif"></a>

<unknown 0>

Section 4 Extending the Library</unknown>

IL has been designed to be very flexible in order to accommodate the wealth of file formats, algorithms, and data sources with which image processing application developers must work. <a href="index.html#REF37709">Figure 11</a> shows how user defined extensions fit into the image object hierarchy. <unknown 0>

<a name="REF37709"><paranum></a>FIGURE 11 Library Extensions</unknown>

<a href="fig/"><img src="/web/19970727074634im_/" width="525" height="324" sgi_src="/d/roots/godot/ilweb/techreport/fig/fig_62.gif"></a>

<unknown 0>

4.1 Adding New File Formats </unknown>

iflFile provides the internal interfaces for programmers to develop their own formats. To support a specific image file format, the following functions must be fully implemented: <unknown 0>Opening/Creating a file The openFile and createFile static methods must open or create the given file. Information about image size, data type, order, page size, and color model must be initialized.</unknown> <unknown 0>Reading from file The getPage function provides the external interface for reading raw image data into memory. getPage must be implemented to read and, if necessary, decompress a tile of data from file.</unknown> <unknown 0>Writing to file The setPage function provides the external interface for writing image data into memory. The image data passed by setPage is provided in raw format and must therefore be compressed before it is written out to the file.</unknown> <unknown 0>Closing a file The closeFile function is used to close an image file after all input and output operations have been completed.</unknown>

IFL determines the supported file formats by reading in a database file that defines all of the supported formats. This database includes a pointer to dynamic shared-objects (DSOs) that contain the code to read and write each format. The database file uses a simple text file format that can be easily extended by the user. Thus, by creating a new DSO with the code to read a user-defined format and adding an entry to the format database, new file types are integrated automatically and seamlessly. An existing IFL or IL-based application will automatically be able to read and write files of the new format without recompiling or even relinking. <unknown 0>

<a name="REF24309">4.2 Adding New Operators</a></unknown>

IL makes it easy to add new operators. IL provides multiple base classes from which new operators can be derived: <unknown 0>ilOpImg This is the most general class derived directly from ilMemCacheImg. The virtuals prepareRequest, executeRequest and finishRequest must be defined. For an operator, the prepareRequest method is responsible for queueing the operations to read from the input image(s). The executeRequest method performs the desired operation, leaving the result in the operator image's cache. The finishRequest method is responsible for cleaning up any resources allocated in prepareRequest. If the operation computes parameters based on the attributes of its input(s), the programmer must define the resetOp method to compute these parameters when the input(s) are changed.</unknown> <unknown 0>ilSpatialImg This class is used as a base for spatial or neighborhood operators. It is derived from ilOpImg and automatically fetches the input data with sufficient padding around the page being computed to support the neighborhood operation. The programmer defines the calcPage method responsible for performing the operation from an input buffer into an output buffer (the operator's cache).</unknown> <unknown 0>ilWarp This class defines a generalized warp algorithm. The programmer supplies an address generation method that maps the output image addresses to the input image. This object is used with ilWarpImg to perform an actual image warp.</unknown> <unknown 0>ilMonadicImg This class makes it easy to add simple single-input point-processing algorithms to the library. Like ilSpatialImg, it performs all I/O for the programmer, who is only responsible for the calcPage method, which is passed an input buffer full of data, and an output buffer to receive the result.</unknown> <unknown 0>ilPolyadicImg This class is identical to ilMonadicImg except that multiple input images are provided and multiple input buffers are passed to calcPage.</unknown> <unknown 0>

4.3 Creating ilImage Class Derivations</unknown>

IL has the flexibility to support the acquisition of images from various sources.

For example, applications requiring analysis of video information that is or can be converted to digital format can use IL for image processing. IL currently provides the protocol required to pass data through image operators for processing. To support access to data from frame digitizers, an object class, ilVideoImg, derived from ilImage, could be implemented. The class definition would implement how data is accessed from the frame grabber, namely, initialization (constructor), getTile, and setTile methods: <unknown 0>constructors Must initialize or perform the necessary operations to establish communication to that source. Upon creation, ilImage attributes such as image size, data type, and organization must be initialized.</unknown> <unknown 0>getTile Must retrieve a specified block of data in the given configuration (component order, data ordering, and data type). The main responsibility of getTile is to retrieve the corresponding block of data from its source. IL provides an object, iflConverter, to perform required conversions.</unknown> <unknown 0>setTile Must store a given block of data to the image source. Data, specified in a given configuration, must be converted (if necessary) before writing it to the source.</unknown>

These functions must invoke a set of control functions provided by the frame-grabber device driver or library. The constructor must execute the required control sequences to establish communication between the process and the frame grabber. Similarly, the reader (getTile) and writer (setTile) must invoke the corresponding set of request functions for reading and writing data to the frame grabber. <unknown 0>

Section 5 Imglab</unknown>

Imglab is an image processing toolkit built on top of the ImageVision Library. It offers easy access to the capabilities of IL operators and images via a graphical network editor. No programming is necessary.

Imglab Features: <unknown 0>

  • · Interactive graphical network editor.</unknown><unknown 0>
  • · Access to IL operators (images) via pull-down menus.</unknown><unknown 0>
  • · Control panels for all operator parameters.</unknown><unknown 0>
  • · Image displays with zoom and pan, animated stepping through 3D-data sets.</unknown><unknown 0>
  • · Volume renderer for 3D-data sets supporting texture mapping algorithms.</unknown><unknown 0>
  • · All network parameters and session set up can be stored and retrieved.</unknown><unknown 0>
  • · Feature extension via DSO-libraries:
    DSOs can be used to extend file formats and include additional operators.</unknown> <unknown 0>

<paranum>FIGURE 12 Imglab's interactive network graphical user interface </unknown>

<a href="fig/fig_I0.gif"><img src="/web/19970727074634im_/" width="416" height="277" sgi_src="/d/roots/godot/ilweb/techreport/fig/fig_I0.gif"></a> <unknown 0>

The Imglab interactive programming environment provides a basic set of algorithms and visualization tools. Each algorithm is encapsulated by an image operator offering components for the input and output images and a panel to control the parameters of the underlying algorithm. The operators can be assembled within a graphical user interface to complex networks to solve a specific task. Any change of the parameters will be automatically propagated through the network causing the operators to re-calculate their image data if necessary.

Imglab is capable to process either 2D or 3D data sets. 3D data can be displayed slice-by-slice or visualized by a volume renderer. Many problems will be solved by simply using the standard operator library of imglab. For more advanced tasks Imglab allows the implementation and dynamic integration of problem specific operators. Section 6 Electronic Light Table (ELT) Object</unknown>

The Electronic Light Table (ELT) operator implements a chain of operators in hardware. This implementation allows viewing and manipulating image files, compressed or not, in real time. ELT also allows for adding graphics and text on top of manipulated images.

Viewing the processed images in real time avoids the necessity of storing them first on disk before viewing them. The ELT application is ideal for analyzing large images (10K X 10K or larger). <unknown 0>

<a name="REF50717"><paranum></a>FIGURE 13 ELT image processing pipeline</unknown>

<a href="fig/"><img src="/web/19970727074634im_/" width="533" height="271" sgi_src="/d/roots/godot/ilweb/techreport/fig/fig_81.gif"></a>

<unknown 0>Each stage of the ELT pipeline has the following purpose:</unknown><unknown 0>R Sets contain the image data at different levels of reduction.</unknown><unknown 0>DeWarp changes the perspective or corrects any image imperfection caused by the image capturing mechanism.</unknown><unknown 0>RotZoom allows you to zoom or rotate the image. ELT selects the correct R-set to input for each specified zoom value.</unknown><unknown 0>Convolve allows you to sharpen or blur the image.</unknown><unknown 0>Histogram feeds data into the LUT to adjust pixel luminance dynamically according to the overall brightness of the displayed image.</unknown><unknown 0>

<a name="REF24554">APPENDIX A </a>List of Operators</unknown> <unknown 0>

A.1 Image Import/Export Functions</unknown> <unknown 0>ilFileImg Opens or creates an image file in a format independent fashion.</unknown> <unknown 0>ilMemoryImg Accesses a contiguous array of data as an ilImage.</unknown> <unknown 0>

A.2 Color Conversion</unknown> <unknown 0>ilFalseColorImg Performs false coloring of multispectral images.</unknown> <unknown 0>ilColorImg Performs color conversion to an indicated color model.</unknown> <unknown 0>ilRGBImg Performs RGB color conversion.</unknown> <unknown 0>ilCMYKImg Performs CMYK color conversion.</unknown> <unknown 0>ilHSVImg Performs HSV color conversion.</unknown> <unknown 0>ilGrayImg Performs grayscale color conversion.</unknown> <unknown 0>ilSGIPaletteImg Converts to the RGB Palette color model.</unknown> <unknown 0>ilSaturateImg Performs color saturation of an image.</unknown> <unknown 0>

A.3 Arithmetic Functions</unknown> <unknown 0>ilAbsImg Computes the pixelwise absolute value on an image.</unknown> <unknown 0>ilAddImg Performs a pixelwise addition of two images.</unknown> <unknown 0>ilAndImg Performs a pixelwise logical-and of two images.</unknown> <unknown 0>ilArithLutImg Provides basic support for arithmetic operations implemented with a look-up table.</unknown> <unknown 0>ilDivImg Performs a pixelwise division of two images.</unknown> <unknown 0>ilDyadicImg Provides basic support for two-image operators</unknown> <unknown 0>ilExpImg Computes the pixelwise exponent of an image.</unknown> <unknown 0>ilInvertImg Computes the complement of an image.</unknown> <unknown 0>ilLogImg Computes the pixelwise log on an image.</unknown> <unknown 0>ilMaxImg Performs a pixelwise maximum or ">" of two images.</unknown> <unknown 0>ilMinImg Performs a pixelwise minimum or "<" of two images.</unknown> <unknown 0>ilMonadicImg Provides basic support for single-image operators</unknown> <unknown 0>ilMultiplyImg Performs a pixelwise multiplication of two images.</unknown> <unknown 0>ilNegImg Computes the pixelwise negation on an image.</unknown> <unknown 0>ilOrImg Performs a pixelwise logical-or of two images.</unknown> <unknown 0>ilPolyadicImg Provides basic support for multi-image operators</unknown> <unknown 0>ilPowerImg Performs a power law scaling of an image.</unknown> <unknown 0>ilSqRootImg Computes the pixelwise square root of an image.</unknown> <unknown 0>ilSquareImg Computes the pixelwise square of an image.</unknown> <unknown 0>ilSubtractImg Performs a pixelwise subtraction of two images.</unknown> <unknown 0>ilXorImg Performs a pixelwise exclusive-or of two images.</unknown> <unknown 0>

A.4 Radiometric Transforms</unknown> <unknown 0>ilHistEqImg Performs histogram equalization of an image.</unknown> <unknown 0>ilHistNormImg Transforms image to desired means and standard deviation.</unknown> <unknown 0>ilHistScaleImg Performs histogram scaling of an image.</unknown> <unknown 0>ilScaleImg Performs a linear scale of an image.</unknown> <unknown 0>ilThreshImg Performs thresholding of an image.</unknown> <unknown 0>

A.5 Geometric Transforms</unknown> <unknown 0>ilAffineWarp Defines a 2D affine coordinate transformation.</unknown> <unknown 0>ilPerspWarp Defines a 2D perspective warp.</unknown> <unknown 0>ilRotZoomImg Rotates, zooms; translates an image with optional flip.</unknown> <unknown 0>ilWarpImg Performs generalized warp on an image.</unknown> <unknown 0>ilPolyWarpImg Performs up to a seventh-order polynomial warp on an image.</unknown> <unknown 0>ilTieWarpImg Performs a two-dimensional warp on an image</unknown> <unknown 0>

A.6 Statistics</unknown> <unknown 0>ilImgStat Computes the histogram, mean, and standard deviation pixel values of an image.</unknown> <unknown 0>

A.7 Non-spatial Domain Transforms</unknown> <unknown 0>ilRFFTfImg Performs forward Fourier transform on an image.</unknown> <unknown 0>ilRFFTiImg Performs an inverse Fourier transform on an image.</unknown> <unknown 0>ilFFTAvg Computes the average power spectrum of an image.</unknown> <unknown 0>ilFConjImg Computes the conjugate of an image and normalizes the complex value by a real factor.</unknown> <unknown 0>ilFCrCorrImg Computes the cross correlation of two images.</unknown> <unknown 0>ilFDivImg Divides two FFT images.</unknown> <unknown 0>ilFDyadicImg Provides support for dual input Fourier domain operators</unknown> <unknown 0>ilFFiltImg Provides support for Fourier filter operators</unknown> <unknown 0>ilFExpFiltImg Applies a Fourier domain filter to a Fourier domain image.</unknown> <unknown 0>ilFGaussFiltImg Applies a Gaussian domain filter to a Fourier domain image.</unknown> <unknown 0>ilFMagImg Accesses only the magnitude values of an FFT image.</unknown> <unknown 0>ilFMergeImg Merges two single-band images and accesses them as an FFT image.</unknown> <unknown 0>ilFMonadicImg Provides support for single input Fourier domain operators</unknown> <unknown 0>ilFMultImg Multiplies two FFT images.</unknown> <unknown 0>ilFPhaseImg Accesses only the phase values of an FFT image.</unknown> <unknown 0>ilFRaisePwrImg Raises the Fourier coefficients of an FFT image by a power in the log domain.</unknown> <unknown 0>ilFSpectImg Computes the spectrum of a fourier domain image</unknown> <unknown 0>

A.8 Spatial Domain Transforms</unknown> <unknown 0>ilBlurImg Blurs an image.</unknown> <unknown 0>ilGBlurImg Performs a Gaussian blur on an image.</unknown> <unknown 0>ilConvImg Convolves an image with specified kernel.</unknown> <unknown 0>ilDilateImg Performs a morphological dilation on an image</unknown> <unknown 0>ilErodeImg Performs a morphological erosion on an image</unknown> <unknown 0>lMaxFltImg Performs a maximum filter on an image.</unknown> <unknown 0>ilMedFltImg Performs a median filter on an image.</unknown> <unknown 0>ilMinFltImg Performs a minimum filter on an image.</unknown> <unknown 0>ilRankFiltImg Performs a rank filter on an image.</unknown> <unknown 0>ilSepConvImg Convolves an image with a separable kernel</unknown> <unknown 0>ilSharpenImg Sharpens an image.</unknown> <unknown 0>ilSpatialImg Provides the basis for generalized spatial or neighborhood operators.</unknown> <unknown 0>

A.9 Edge, Line, & Spot Detection</unknown> <unknown 0>ilCompassImg Performs a 2D, 3x3 gradient transform on an image.</unknown> <unknown 0>lLaplaceImg Performs a 2D, 3x3 Laplace transform on an image.</unknown> <unknown 0>ilRobertsImg Computes the gradient vector of an image by performing two 2D spatial convolutions in the x and y directions, using the 3x3 Roberts kernels.</unknown> <unknown 0>ilSobelImg Computes the gradient vector of an image by performing two 2D spatial convolutions in the x and y directions, using the 3x3 Sobel kernels.</unknown> <unknown 0>

A.10 Miscellaneous</unknown> <unknown 0>ilLutImg Performs look-up table manipulation of an image.</unknown> <unknown 0>ilBlendImg Blends two images.</unknown> <unknown 0>ilCombineImg Combines two images based on an ROI mask.</unknown> <unknown 0>ilCompoundImg Abstract class to manage a subchain as if it was a single object.</unknown> <unknown 0>ilConstImg Constant valued image</unknown> <unknown 0>ilNopImg Performs page size, data type, order and coordinate space conversions on an image.</unknown> <unknown 0>ilPiecewiseImg Performs a look-up translation of an image using a piecewise linear mapping function.</unknown> <unknown 0>ilMergeImg Merges several images into one.</unknown> <unknown 0>ilRoiImg Masks accesses to an image by an ROI mask.</unknown> <unknown 0>ilSubImg Selects a rectangular subregion and/or component subset of an image.</unknown> <unknown 0>ilSwitchImg Implements a switch construct in an image operator</unknown> <unknown 0>chain.</unknown> <unknown 0>

A.11 Image File Support (IFL)</unknown> <unknown 0>iflBitArray Provides a limited, subscriptable bit array </unknown><unknown 0>iflClassList Creates a class inheritance chain.</unknown> <unknown 0>iflColor Defines a few convenience functions for obtaining info on color models.</unknown> <unknown 0>iflColormap Provides the base class for lookup tables.</unknown> <unknown 0>iflConfig Defines configuration of pixel data</unknown> <unknown 0>iflConvIter Provides an iterator for converters. It is used to step to the beginning of each row shared in common between two converters.</unknown> <unknown 0>iflConverter Handles type conversion and reorganization between arbitrary rectangular data buffers.</unknown> <unknown 0>iflCoord Contains structures to hold coordinates with arithmetic operations.</unknown> <unknown 0>iflDataSize() Manipulates the size of IL data types</unknown> <unknown 0>iflDatabase Describes the capabilities of a particular image file format.</unknown> <unknown 0>iflDefs Contains standard definitions required by the Image Format Library.</unknown> <unknown 0>iflDictionary Implements a dictionary of named elements</unknown> <unknown 0>iflError Contains error codes, error handling, and assertion macros used by the IFL library.</unknown> <unknown 0>iflFile Contains an abstraction of a handle to an image file.</unknown> <unknown 0>iflFileConfig Describes the configuration of an iflFile. It is used with the iflFile: create() calls to query file configurations.</unknown> <unknown 0>iflFormat Describes the capabilities of a particular image file format.</unknown> <unknown 0>iflHashTable Contains the base class from which hash table implementations can be derived.</unknown> <unknown 0>iflList Contains the base class for a simple doubly-linked list.</unknown> <unknown 0>iflLut Defines a lookup table.</unknown> <unknown 0>iflMinMax Contains the functions for performing minimum and maximum comparisons</unknown> <unknown 0>iflOrientation Transposes the orientation of an image's axis.</unknown> <unknown 0>iflPixel Defines a pixel.</unknown> <unknown 0>iflSGIColormap Contains the functions that create or access color maps.</unknown> <unknown 0>iflSize Defines the size of an image.</unknown> <unknown 0>iflTile Defines a three-dimensional rectangle of image data.</unknown> <unknown 0>iflTileIter Cycles through the pages spanning a tile.</unknown> <unknown 0>iflTypeNames Provides a some convenience functions to get the ASCII string for some of the enumerated types used by IFL.</unknown> <unknown 0>iflTypes Defines the image data types, pixel component ordering, supported Color Models, supported orientations, supported compression schemes, and flip modes.</unknown> <unknown 0>

A.12 Display</unknown> <unknown 0>ilFrameBufferImg Abstract class for displayed images.</unknown> <unknown 0>ilXWindowImg Displays an image in an X window with X-rendering.</unknown> <unknown 0>ilDisplay Manages the display of images in an X or OpenGL window.</unknown> <unknown 0>lViewer Adds some basic X event loop support to the ilDisplay object.</unknown> <unknown 0>ilView Maps an ilImage or XImage to a rectangular area within an ilDisplayImg.</unknown> <unknown 0>ilStereoView Maps a pair of images to a rectangular area within an ilDisplayImg and displays them as a stereo pair.</unknown> <unknown 0>

A.13 ELT</unknown> <unknown 0>ilELTimg Implements functions for Electronic Light Table.</unknown> <unknown 0>ilELTRoamer Supports roaming look-ahead and zooming look-ahead for ELT applications.</unknown> <unknown 0>ilELTrset Encapsulates all information related to an R-set. </unknown><unknown 0>

A.14 Viewkit</unknown> <unknown 0>ilVkDetailView Displays detailed image pixel information.</unknown> <unknown 0>lVkFileInfo Displays information about an image file.</unknown> <unknown 0>ilVkHistGraph Displays graph of histogram for an image.</unknown> <unknown 0>lVkImgAttributes Displays editable image attributes.</unknown> <unknown 0>ilVkImgInfo Displays information about an image.</unknown> <unknown 0>ilVkRotZoomView Rotates and zooms a single ilImage</unknown> <unknown 0>ilVkSaveDialog Puts up an dialog to specify an image file to save to.</unknown> <unknown 0>ilVkView Statically displays a single ilImage.</unknown> <unknown 0>ilVkViewer Dynamically displays multiple ilImages.</unknown> <unknown 0>ilVkWindow Top-level window for displaying multiple images.</unknown>