As described in Chapter 3 of Inside Macintosh: QuickTime , the Image Compression
Manager performs compression and decompression by invoking image compressor and
decompressor components. These components, calledcodecs , present a standard
interface to the Image Compression Manager using the Component Manager. But each
codec is unique because each implements a different compression and decompression
algorithm. Codecs can vary greatly in the three major characteristics that are used to
judge image compression algorithms: compression ratio, compression speed, and image
quality. QuickTime 2.0 ships with eight codecs that can be selected for use by your
QuickTime application under various conditions. In addition, users or third-party
products can install custom codecs into the system by simply placing them in the
Extensions folder.
With all the choices for image compression and decompression, the only way to choose
the best codec for a particular purpose is to have some understanding of all the codecs
available on your system. Inside Macintosh provides general descriptions of the
standard QuickTime codecs, but detailed information is important in making an
intelligent codec selection. The way to find this detailed information is to communicate
programmatically with the codec and request its capabilities through the codec call
CDGetCodecInfo. As described inInside Macintosh: QuickTime Components, this call
returns a compressor information structure.
For example, information about what pixel depths a compressor supports for storing
image data is important to choosing the right codec. If your application creates and
compresses a picture, the decision of whether to create the picture in 8-bit, 16-bit,
or 32-bit color can be based partially on what pixel depths the compressor supports.
If the compressed data can store only 16 bits of color information, it would be
inefficient to create a picture with 32 bits of color.
Accompanying this column on this issue's CD is the sample application
GetCodecInfoApp, which (by calling CDGetCodecInfo) allows you to easily obtain
detailed information about codecs installed in your system. I'll discuss GetCodecInfoApp
and point out some characteristics that should be considered in choosing a codec.
USING CODECS
There are actually two separate parts to a codec: one for the compression and one for
the decompression. Not all codecs provide both; nevertheless, all compressor and
decompressor combinations are referred to as codecs. One example of a
decompression-only codec is the codec that comes with the QuickTake 100 digital
camera from Apple. The hardware in the QuickTake 100 camera performs the
compression and downloads compressed data to the Macintosh. The Macintosh only needs
to perform decompression.
A compressor is a component of type compressor-ComponentType ('imco') and a
decompressor is a component of type decompressorComponentType ('imdc'). Detailed
information on writing a codec is provided in Chapter 4 ofInside Macintosh: QuickTime
Components . But to select the appropriate codec to use, you don't need to do any
programming; you can simply use GetCodecInfoApp, without any need to understand
how it was written. This application creates a text file containing a report of all the
codec components installed in your system. For example, the output for the Cinepak
codec looks like this:
Compressor Name: Cinepak
------------------------------------
- version = 1
- revisionLevel = 1
- vendor = appl
- compressionAccuracy = 128
- compressionLevel = 128
- minimum height = 1
- minimum width = 1
- compress pipeline latency = 0
- compression capabilities:
directly compresses 32-bit pixel maps
supports temporal compression
can recompress images without accumulating errors
can rate constrain to caller defined limit
- compression format:
can store images in 24-bit color
can store images in 8-bit grayscale
can store custom color table
compressed data requires non-key frames to be
decompressed in same order as compressed
- estimated compression speed:
640x480 32-bit RGB = 11485 milliseconds
Decompressor Name: Cinepak
------------------------------------
- version = 1
- revisionLevel = 1
- vendor = appl
- decompressionAccuracy = 128
- minimum height = 1
- minimum width = 1
- decompress pipeline latency = 0
- decompression capabilities:
directly decompresses into 32-bit pixel maps
supports temporal compression
can recompress images without accumulating errors
can rate constrain to caller defined limit
- decompression format:
can decompress images from 24-bit color
compressed format
can decompress images from 8-bit grayscale
compressed format
can store custom color table
compressed data requires non-key frames to be
decompressed in same order as compressed
- estimated decompression speed:
640x480 32-bit RGB = 56 milliseconds
GetCodecInfoApp gets information about codecs by calling the codec's CDGetCodecInfo
function, which all codecs must support; if you're writing a codec, it's important to
report your capabilities with this function. To measure the codec's speed, the
application actually passes it an image to compress or decompress, and reports the
result.
The Image Compression Manager function GetCodecInfo can also be used to
obtain information about codecs, but only for compressor codecs; you won't be able to
get information about decompression-only codecs with GetCodecInfo. *
An example of a characteristic you can determine with GetCodecInfoApp is what pixel
depths the decompressor can decompress directly into. This is important because it
affects the speed of the image decompression. If the codec can't decompress directly
into the destination pixel map, the Image Compression Manager will have to
decompress into an offscreen buffer and move the image data into the destination after
converting the pixel depth. This results in additional memory and processor bandwidth
requirements. If you know exactly what pixel depths a decompressor supports, you can
set up the destination for the best performance.
Most codecs support only a limited number of pixel depths for the compressed data
storage format. For example, the Video Compressor will store image data only in
16-bit color. If you compress a 32- bit color image, you'll lose information, since the
compressed format will store the equivalent of 16 bits of data. The pixel depth for the
compressed data storage format also determines which of the different compression
settings are available -- for example, the pixel depth pop-up menu for Compression
Settings displayed by the standard image-compression dialog component (used, for
example, by Picture Compressor, an application that's part of the QuickTime Starter
Kit) will only allow you to choose Color for the Video Compressor. The Animation
Compressor is one of the few compressors that will store compressed data in nearly all
pixel depth formats: Black and White, 4 Grays, 4 Colors, 16 Grays, 16 Colors, and so
on.
When compressing movies, you'll often want to select a codec that supports temporal
compression; not all codecs do. Temporal compression is the use of frame differencing
to compress consecutive image frames by skipping data that doesn't change from frame
to frame. Temporal compression is useful only for sequences of images stored as
QuickTime movies. Knowing which codecs support temporal compression will allow
you to choose the best codec for compressing sequences.
If you're compressing pictures with scientific data, it may be extremely important
that there be no image quality loss. In this case, you'll want to look for a codec that
supportslossless compression. For example, the Photo Compressor (JPEG codec) is a
lossy codec because even at the highest quality setting, there may still be some loss of
image quality. On the other hand, the Animation Compressor is lossless at higher
quality settings and will preserve every pixel value.
There are many additional features a codec may support that are important to know.
For example, certain codecs will support data spooling so that only portions of the
compressed data need to be read into memory at any one time. This can be a
requirement when working with very large compressed images that will be displayed
in systems with limited memory. Another example is support for stretching to double
size during decompression. This is extremely useful, since the performance is much
greater if the scaling is performed during decompression rather than as a separate
step after decompression.
SOME RECOMMENDATIONS
For most video clips, the Cinepak Compressor is the recommended codec. As you can see
from GetCodecInfoApp's report, this codec is very slow in compression. However, its
decompression speed and compression level are excellent, making it the best choice for
most video data for CD-ROM playback.
An alternative to Cinepak is the Video Compressor. Since its compression speed is
fairly quick, it's better for an application that requires fast compression.
If your source material is animation graphics in a movie, there are several
compressors that may do the job. The Animation Compressor and Graphics Compressor
may be equally suitable. In this case, you may need to experiment to determine which
is the best codec to use. Finally, if you're compressing photo images, the Photo
Compressor is the best codec to use. It has only moderate compression and
decompression speed, but the compression ratio and quality are excellent and the
compression ratio scales accordingly with image quality. If you want better image
quality at the expense of larger compressed data size, you can easily achieve this with
the Photo Compressor.
PRESSING ON
If you're writing a codec, you can see from this column that it's very important to
properly report the codec's capabilities; GetCodecInfoApp may be useful for you to
verify that your codec is doing this properly. For the rest of you, I hope this column
has provided some insight on how to choose the right codec for producing the best
movies and compressed images.
JOHN WANG (AppleLink WANG.JY) used to be a proud member of the PIGs (Printing,
Imaging, and Graphics group) in Apple's Developer Technical Support group. But he
decided that there are other challenges in life and programming. So now John spends
his entire day waiting for MPW to compile code that he's writing in his software
engineering role in the Image Capture group. Just in case you fail to notice, we're sure
he'd like us to point out that he makes a gratuitous plug for his group's product, the
QuickTake 100 digital camera, in this column. *
Thanks to Peter Hoddie, Don Johnson, Kent Sandvik, and Nick Thompson for
reviewing this column. *