Manipulating Pixel Map Images
QuickDraw's facilities for copying pixel maps continue to evolve. With
addition, colorizing (copying a black-and-white image with the foreground or
background set to a color) now is done in RGB space, and the classic transfer
modes OR, BIC, and XOR work correctly with colored images.
Copying With Masks
which copied a bitmap using a transfer mode and a region mask, was modified so
that a pixel map could be copied by the same method, as shown in the Figure
below.
Copying pixel maps with CopyBits
allowed a bitmap to act as a mask when copying bitmaps. With system 7.0, the
CopyMask procedure has been expanded to allow a pixel map to be the mask,
as shown in the Figure below.
Copying pixel maps with CopyMask
as copy modes and a mask region, as shown in the Figure below.
Note: Pixel map records are always copied using the color table of
the source pixel map for source information, and the color table of
the current graphics device record for destination color information.
(The color table attached to the destination pixel map is ignored.) If
you need to copy to an offscreen pixel map with characteristics
differing from those of the current graphics device (usually the main
screen), you should create an appropriate offscreen graphics device
record and set it as the current graphics device before the copy
operation.
(For information about offscreen graphics, see
When the pixel map mask is 1 bit deep, it has the same effect as a bitmap
mask: a black mask bit means that the pixel is to take the source value; a white
mask bit means that the pixel is to take the destination value. Intermediate
values in deeper pixel map masks specify that a weighted average is to be taken
between the source and destination pixel maps. Within each pixel, the
calculation is done in RGB space, on a color component basis. A gray pixel map
mask (high values for the red component in all pixels) filters out red values
coming from the source pixel map.
Setting either the foreground or background (or both) to colors other than
effects. Before system 7.0, the colorizing was done by indexing, yielding
arbitrary results unless the color table had been arranged carefully. Now your
application can colorize pixels in RGB space (where $FFFF represents the full
intensity of a component), so that setting the foreground to blue and the
background to red, for example, turns a gray-scale image into appropriate
shades of blue and red.
You can decide what to do with source pixels on a color component basis. Your
application can
• pass a pixel's component, un changed, by setting the foreground for
that component to $0000 and the background to $FFFF
• invert them by setting the foreground for that component to $FFFF and
the background to $0000
• zero them by setting both foreground and background for that
component to $0000
• force them to 1 by setting both the foreground and background for that
component to $FFFF
Note that arithmetic transfer modes have no colorizing effect.
The classic transfer modes OR, BIC, and XOR, which previously were
problematic with color images, now work as you would expect:
• Using the OR mode when you copy an image you are transferring to a
white background always results in the source image, regardless of the
destination depth.
• Using the BIC mode when you copy an image causes black in the source
image to erase, resulting in white in the destination image.
• The XOR mode inverts black in the source image but not white, at all
destination depths, including 16-bit and 32-bit direct pixels.
When you work with color pixels, transfer modes produce different results
on indexed and direct devices.
You can use a new text drawing mode, grayishTextOr, to draw dimmed text on
the screen. If the destination device is color, it draws with a blend of the
foreground and background colors. If the destination device is black and white,
the grayishTextOr mode dithers black and white. Note that grayishTextOr is not
a standard transfer mode in that currently it is not stored in pictures and
printing with it is un defined. (It does pass through the bottleneck procedures.)
The primary use for grayishTextOr is to display disabled user interface items.
Dithering
technique of mixing existing colors to create the effect of additional colors.
procedures do their best to provide error diffusion during the copy operation.
As with arithmetic transfer modes, dithering ignores hidden colors. Therefore,
when you copy to an indexed device, color matching is limited by the resolution
of the inverse table for the destination graphics device. (See the section
results for most images-for example, it allows you to shrink images more
efficiently. However, dithering does have drawbacks: it is slower, and because
of error diffusion, a clipped dithering operation does not provide
pixel-for-pixel equivalence to the same unclipped dithering operation. Clipped
XOR dithered copies, for example, do not perform as erase operations.
CopyDeepMask use plain copy mode instead of dithering. (This may change
in future versions.)
Using plain copy mode (without dithering), your application does color
mapping on a pixel-by-pixel basis-no errors are accumulated, and hidden
colors are ignored. If the source pixel map is indexed and a color search
color in the color table. If the source is a direct pixel map and a search
procedure is present, the procedure is called once for each color in the source
pixel map. (With a source pixel map of many colors, this can take a long time.)
Color QuickDraw never uses dithering if you copy to a direct pixel map,
but you can always use dithering when copying to an indexed pixel map.
Resizing Images
When copying from direct pixel maps, if the destination rectangle is smaller
produce the destination pixels, maintaining high-quality images when
shrinking them.
Color QuickDraw also averages pixels when shrinking indexed images
using dithering. Shrinking 1-bit images using dithering can produce much
better representations of the original images than without using dithering.
Luminance Mapping
computes the luminance, or intensity of light, of the desired color and uses
that value to determine the appropriate gray value to draw. A gray-scale
device can be a color device that the user sets to gray-scale mode; for such a
linear ramp from white to black, in the device's CLUT. A gray-scale device can
also be a device whose color table consists only of grays if the animated entries
are not counted.
been enhanced to recognize additional standard color table IDs. As described in
You can obtain the default gray-scale color table for a given pixel depth by
the following Table.
Table The default color tables for gray-scale devices
pixelSize ctID com position
1 33 Black, white
2 34 Black, 33% gray, 66% gray, white
4 36 Black, 14 shades of gray, white
8 40 Black, 254 shades of gray, white
You can obtain the equivalent default color tables by adding 64 to the pixel
information. )
Table The default color tables for color devices
pixelSize ctID com position
2 66 Black, 50% gray, highlight color, white
4 68 Black, 14 colors including a highlight color, white
8 72 Black, 254 colors including a highlight color, white
Image Resolution
Color QuickDraw supports pixel maps of resolutions other than 72 dpi. In
the past, applications have accepted pixel maps of a certain number of rows
and columns and assumed that they were generated on a 72-dpi device. Such
pixel maps were usually copied and printed at a 72-dpi resolution, lending the
With the advent of frame grabbers and scanners, many pixel maps have dpi
resolutions of 150, 200, 300, or greater. A user expects pixel maps to
display an approximation of the information on a 72-dpi display but to print
on a higher resolution device to the best of the device's ability.
Displaying Variable-Resolution Pixel Maps and Pictures
The resolution of a pixel map record, measured in dpi, is contained in its hRes
and vRes fields. These values are expressed as fixed-point integers.
When importing a picture, your application should check the picture type to
and vRes values in the picture header. For information on determining a
grafProcs field in the color grafPort record) during playback. When
1. make sure the source is a pixel map record by checking that the high
2. read the hRes and vRes information from the source pixel map record
(At this point, the source rectangle field indicates the size of the source in
pixels at the resolution specified by the hRes and vRes fields.)
To display a picture at another resolution, your application should compute
the destination rectangle field value appropriately. For example, if the source
resolution is 300 dpi and you want to display it at 75 dpi, then your
application should compute the destination rectangle width and height as 1/4 of
that of the source rectangle.
Exporting Pixel Map Records
When exporting pixel map records, your application should ensure that the
hRes and vRes fields accurately reflect the image data. During picture
appropriate for display at 72 dpi. If you want an entire picture to be a
Converting a Bitmap to a Region
region, the resulting region is the same as the bitmap.
clicks on the black pixels in a bitmap, or drag the outline of a bitmap using
Determining Whether Drawing Is Complete
operations have finished in a grafPort. This function is useful if your
application is executing in an environment with a graphics accelerator, where
drawing operations may proceed asynchronously.