Overview of the ICM

The Image Compression Manager provides your application with an interface for compressing and decompressing images and sequences of images that is independent of devices and algorithms.

Uncompressed image data requires a large amount of storage space. Storing a single 640-by-480 pixel image in 32-bit color can require as much as 1.2 MB. Sequences of images, like those that might be contained in a QuickTime movie, demand substantially more storage than single images. This is true even for sequences that consist of fairly small images, because the movie consists of such a large number of those images. Consequently, minimizing the storage requirements for image data is an important consideration for any application that works with images or sequences of images.

The Image Compression Manager compresses images by invoking image compressor components and decompresses images using image decompressor components. Compressor and decompressor components are code resources that present a standard interface to the Image Compression Manager and provide image-compression and image-decompression services, respectively. The Image Compression Manager receives application requests and coordinates the actions of the appropriate components. The components perform the actual compression and decompression. Compressor and decompressor components are standard components and are managed by the Component Manager.

Because the Image Compression Manager is independent of specific compression algorithms and drivers, it provides a number of advantages to developers of image-compression algorithms. Specifically, compressor and decompressor components can

• present a common application interface for software-based compressors and hardware-based compressors.

• provide several different compressors and compression options, allowing the Image Compression Manager or the application to choose the appropriate tool for a particular situation.

Data That Is Suitable for Compression

One way to represent an image is with a pixel map, which stores a color for every pixel. For most images, however, a pixel map is an inefficient storage format. For example, a pixel map containing a solid black image would contain the color black stored over and over and over again. By compressing the image, some of this redundant information can be eliminated. The compressed image can occupy much less storage than a pixel map and can be decompressed to a pixel map when necessary.

In addition, human perception of visual images exhibits special qualities that can be exploited to further compress image data. Image-compression algorithms take advantage of these properties to reduce the amount of information required to describe an image well enough to allow a person to see it.

A lossless compression technique can recreate an exact copy of the original image from the compressed form. Small changes in the image are not objectionable in most applications, however, so most compressors sacrifice some accuracy in order to further decrease the size of the compressed data. However, the compressor carefully chooses the data to omit so that the human visual system compensates for the loss and fools the user into seeing what appears to be the original image.

The Image Compression Manager works only with image data. The Image Compression Manager is primarily useful for compressing pictures that have pixel map images, such as those obtained from scanned still images or digitized video images, or from paint or three-dimensional rendering applications. You do not achieve significant compression treating pictures that are stored as groups of graphics primitives, such as those created by drawing, computer-aided design (CAD), or three-dimensional modeling applications. These applications create images in a compact format that precisely states the characteristics of the objects in the image. In fact, if you were to convert such images to pixel map representations and then compress the resulting image with the Image Compression Manager, you would probably end up with a larger, less precise image than the original. If a picture contains both primitives and pixel map image data (such as text or lines drawn over a painted or digitized image) the Image Compression Manager compresses the pixel map data and leaves the graphics primitives unchanged.

The Image Compression Manager also provides services for compressing and decompressing sequences of images or frames (another term for a single visual image in an image sequence). When processing a sequence, compressors may perform temporal compression, compressing the sequence by eliminating information that is redundant from one frame to the next. This temporal compression differs from spatial compression, which is performed on individual images or frames within a sequence. You may use both techniques on a single sequence.

Compressor components perform temporal compression by comparing the current frame in a sequence with the previous frame. The compressor then stores information about only those pixels that change significantly between the two images. When adjacent images contain substantially similar visual information, as is often the case in movies, temporal compression can significantly reduce the amount of data required to describe the images in the sequence. Your application indicates the desired quality level for the compressed image. The compressor uses this value to govern the extent to which it takes advantage of temporal redundancy between images. There is also a spatial quality level that you can use to control the amount of spatial compression applied to each individual image. Both of these quality values govern the amount of accuracy that is lost in the compressed image.

Note that the Image Compression Manager does not maintain any time information for an image sequence. Rather, the Image Compression Manager maintains the order and content of the images in the sequence while the Movie Toolbox handles all timing considerations.

Storing Images

The Image Compression Manager can compress two kinds of image data: pictures and pixel maps. Pictures may be stored in memory, in a resource, or in a PICT file. Pixel maps are normally stored in a window or offscreen buffer. When compressing an image from a PICT file, the Image Compression Manager provides facilities that allow applications to spool data to and from the disk file, as appropriate to the operation. These application-provided data-loading and data-unloading functions allow arbitrarily large images to be compressed or decompressed without requiring large amounts of memory.

Applications must convert images that are not stored as pictures or pixel maps into one of these formats before compressing them. The Image Compression Manager contains several high-level functions that make it quite easy for applications to work with compressed images that are stored as PICT files, as discussed in the next section.

Working With Pictures

The Image Compression Manager provides a set of functions that allow applications to work easily with compressed pictures stored in version 2 PICT files. These functions constitute a high-level interface to image compression and decompression. Applications that require little control over the compression process may use these functions to display pictures that contain compressed image data.

Existing programs can display (without changes) pictures that contain compressed image data. When the Image Compression Manager is installed on a system, it installs a new StdPix graphics function (see Working With the StdPix Function for more information on the StdPix graphics function). This function handles all requests to display compressed images. Whenever an application issues the standard QuickDraw DrawPicture routine to display an image that contains compressed image data, the StdPix function decompresses the image by invoking the Image Compression Manager. The function then delivers the decompressed image to the application.

The Image Compression Manager also provides a simple mechanism for creating a picture that contains compressed image data. For example, to place an existing compressed image into a picture, your application could open the picture with QuickDraw’s OpenPicture (or OpenCPicture) function and then call the Image Compression Manager’s DecompressImage function, as if you were going to display the image. The Image Compression Manager places the compressed image and the other data that describe the image into the picture for you.

The Image Compression Manager stores the following information about a compressed picture:

• the image description, which describes the compression format and characteristics of the compressed image data

• the compressed data for the image

• the transfer mode (source copy mode, dither copy mode, and so on)

• the matte pixel map

• the mask region

• the mapping matrix

• the source rectangle of the image

The Image Compression Manager stores this information in the picture as a new PICT opcode (described in the following paragraphs). When an application draws the compressed picture on a Macintosh computer that is running the Image Compression Manager, the StdPix function instructs the Image Compression Manager to decompress the image. If an application tries to read a picture file that contains compressed data on a Macintosh that does not have the Image Compression Manager installed, the system ignores the new opcodes and displays a message that indicates that the user needs QuickTime in order to display the compressed image data. The message states “QuickTime and a <Codec Name> decompressor are needed to see this picture”.

The Color QuickDraw version 2 picture format includes PICT opcodes for compressed and uncompressed QuickTime images. (An opcode is a hexidecimal number that represents drawing commands and the parameters that affect those drawing commands in a picture.)

The PICT opcodes for compressed and uncompressed QuickTime images are

• opcode $8200, which signals a compressed QuickTime image

• opcode $8201, which signals an uncompressed QuickTime image

Table 1-1 gives an overview of the opcode for QuickTime compressed pictures.

The MaskSize field of opcode $8200 is followed by five variable fields:

• The matte image description, which contains the image description structure for the matte. The variable size is specified in the first long integer in the opcode. This field is not included if the MatteSize field is 0.

• The matte data, which contains the compressed data for the matte. The size of this field is defined by the MatteSize field listed in Table 1-1. This field is not included if the MatteSize field is 0.

• The mask region, which contains the region for masking. The size of this variable is defined by the MaskSize field listed in Table 1-1. This field is not included if the MaskSize field is 0.

• The image description structure for this data. The size of this variable is specified in the first long integer in the idSize field of this image description.

• The image data, which contains the compressed data for the image. The size of the image data is specified in the image description’s dataSize field.

See The Image Description Structure for details on the idSize and dataSize fields.

Table 1-2 provides an overview of the structure of uncompressed QuickTime images.

The MatteRect field of opcode $8201 is followed by three variable fields and a subopcode:

• The matte image description, which contains the image description structure for the matte. The size of this variable is specified in the first long integer in this opcode. This field is not included if the MatteSize field is 0.

• The matte data, which contains information for the matte. The size of this variable is defined by the MatteSize field.

• A subopcode (2 bytes in length) which describes the image and mask and is entirely within the other opcode. Its size is included in the size for the main opcode; hence it is not included if the QuickTime opcode is skipped. This subopcode can be either $98, $99, $9A, or $9B.

• The data for the subopcode variable which contains information for the image.

Understanding Compressor Components

This section discusses key attributes of compressor components and the functional interfaces these components must support. (Compressor components here refers to both image compressor components and image decompressor components.) This information is intended for developers of compressor components. Application developers do not need to be familiar with this material to use the Image Compression Manager.

A compressor component is a code resource that provides image compression or decompression services for image data. These components may also utilize additional hardware to provide their services. Compressor components are registered by the Component Manager, and they present a standard set of function interfaces to the Image Compression Manager. A compressor can be a system-wide resource, or it can be local to a particular application.

Applications never communicate directly with compressors. Applications request compressor services by issuing the appropriate Image Compression Manager functions. The Image Compression Manager then performs its necessary processing before invoking the compressor. Of course, an application could install its own compressor component. However, any interaction between the application and the compressor is still managed by the Image Compression Manager.

The Image Compression Manager knows about two types of compressor components. Components that can compress image data carry a component type (described by the compressorComponentType data type) of 'imco' and are referred to as compressors. Components that can decompress images have a component type (described by the decompressorComponentType data type) of 'imdc' and are called decompressors. The value of the component subtype indicates the compression algorithm supported by the component. All compressor components with the same subtype must be able to handle the same format of compressed data. During decompression a component should handle all variations of the data specified for a subtype. Conversely, while compressing an image a compressor must not produce data that decompressors of the same subtype cannot handle during decompression.

The Image Compression Manager defines four callback functions that may be provided to compressors or decompressors by applications. A callback function is an application-defined function that is invoked at a specified time or based on specified criteria. These callback functions are data-loading functions, data-unloading functions, completion functions, and progress functions. Data-loading functions and data-unloading functions support spooling of compressed data. Completion functions allow compressors and decompressors to report that asynchronous operations have completed. Progress functions provide a mechanism for compressors and decompressors to report their progress toward completing an operation. For more information about these callback functions, see Application-Defined Functions.

Banding and Extending Images

Occasionally a compressor component may not be able to accommodate the destination rectangle for an image decompression or the source for an image-compression operation. This situation may result from compressors that are optimized to work at certain depths or that cannot perform scaling, translation, dithering, or masking during decompression. In such circumstances the Image Compression Manager allocates a temporary buffer that is acceptable to the compressor component and breaks the image up to fit into that new buffer. Since there often is not enough memory to allocate a buffer to hold the entire image, the Image Compression Manager may allocate one that holds a band of the image. A band is one horizontal piece of the image. Its height is some portion of the desired image height (before scaling or rotation), and it is at least as wide as the desired image.

The height of the band is determined both by the amount of memory available and the block size of the compressor component. The block size of a compressor is the natural size at which it handles images, and it is peculiar to the image-compression algorithm. The block size for the photo compressor is usually 16 pixels by 16 pixels, for example. Usually the block width and height are equal, but this is not always the case. The minimum height of a band is one strip of blocks. A strip is defined to be a part of an image that is as high as the block height (for the compressor in question) and as wide as the band. The width of a band is either the width of the desired unscaled image, or that width increased by an extension.

Figure 1-1 shows the measurements of several image bands.

Some compressors can only handle images with dimensions that are a multiple of their block size. If the desired image does not comply with this restriction in either dimension, the Image Compression Manager extends the band on the right side and bottom by the amount required to meet the needs of the compressor. During compression, the compressor fills the extended region with the same pixel value as the pixels adjacent to the extension. During decompression, the Image Compression Manager writes only the pixels that are part of the source image. The extended portion remains only in the offscreen buffer.

Fast Dithering

QuickDraw provides a means of displaying images with high color resolution in pixel maps or on screens with lower color resolution. By dithering the destination image, QuickDraw fools your eyes into seeing colors that are not actually available on the display screen. Unfortunately, the error-diffusion technique used by QuickDraw takes longer than just drawing pixels by directly looking them up in a color table. The drawing delays imposed by standard dithering are unacceptable when working with movies.

To alleviate this problem, Apple has developed a technique that allows faster dithering to destinations that use 8 bits per pixel. Fast dithering uses lookup tables created by the Image Compression Manager. All the decompressors supplied by Apple can use fast dithering.

Apple decompressors use fast dithering when copying from image band buffers to 8-bit destinations. If the accuracy for decompression is above normal, then the decompressors use true error diffusion rather than fast dithering. Note that video sequences are normally displayed at normal or low accuracy so that you can obtain maximum display speed during decompression.