December 94 - GRAPHICAL TRUFFLES
A Space-Saving PICT Trick
GUILLERMO A. ORTIZ AND DAVE JOHNSON
On the Macintosh, the standard file format for storing images is the PICT format. When pixel maps
are stored in PICTs, the color table is always included. If you have a large number of PICTs that all
use the same color table, however, it's redundant to have a separate copy of the color table in each
PICT. It would be better to strip the color tables out of the PICTs themselves, store only one copy
of the color table on disk, and use that color table for all the PICTs. This column describes a simple
way to do that.
OF COLOR TABLES AND PICTS
One of the really neat features of the Macintosh and QuickDraw is that the process to store a pixel
image in a picture is really simple. The code can be as simple as opening a picture to start PICT
recording, doing a CopyBits of a PixMap onto itself, and closing the picture; QuickDraw does the
newPict = OpenPicture(&offRect);
CopyBits(srcPix, srcPix, &offRect, &offRect,
Here I use OpenPicture for simplicity, but as pointed out in
Inside Macintosh: Imaging With QuickDraw , you should
really use OpenCPicture, especially if you want to specify a resolution other than 72 dpi. *
This code works great, but there's a catch: every time you do this, the whole PixMap -- including its
color table -- is recorded into the picture. For a PixMap that's 8 bits deep (256 colors), the color
table takes a little over 2K. This may not be that big a deal for one or two pictures, but what if you're
pressing a CD withthousands of pictures that use the same color table? Suddenly all those embedded
color tables add up to a significant chunk of space. For pictures delivered on floppy disks, space may
be at even more of a premium, and those extra few kilobytes might matter. Also note that if you
create PICTs with multiple calls to CopyBits, a color table is stored witheach PixMap in the picture,
making the problem even worse.
LEARNING TO SHARE
More often than not, a series of PICT files will all use the same color table (usually the default color
table). In these cases it would be much more economical if we could somehow store only one copy of
the color table, and then share it amongall the pictures. As it turns out, doing that is pretty easy. The
solution has two parts: first, we need to be able to create PICTs that don't include a color table, and
later we need to be able to draw those same PICTs using the appropriate color table, stored
separately from the picture.
JUST SAY NIL
The first part of the solution is easy. In a PixMap, the pmTable field contains a handle to a color
table. When recording a picture, QuickDraw simply stores the color table specified by the pmTable
field into the PICT. But if pmTable is nil, there's no color table to put in the picture, so its size ends
up smaller. Only one extra line of code is needed to do this:
// Set PixMap color table handle to nil.
(*srcPix)->pmTable = nil;
Naturally, you'll need to save the color table handle beforehand, and afterward restore it before
disposing of the PixMap, so that QuickDraw can dispose of all the pieces correctly. But even more
important, you'll use the color table handle to create a 'clut' resource that you can save and that can
later be used to draw the PICT with its correct colors. The sample program named CLUTLess,
included on this issue's CD, contains the complete code to do this.
In reality, QuickDraw adds more than just a nil color table handle to the picture when the code
described above is executed. The reason for this is that some applications assume that PixMaps in a
picture always have a color table, and they would die horrible deaths if QuickDraw didn't somehow
protect them from themselves. To avoid this problem, QuickDraw stores a color table "stub" into the
PICT that it recognizes as such when playing back the picture.
If you simply call DrawPicture to display the "clutless" picture you've made, QuickDraw will see the
color table stub and create a color table for the picture on the fly. This color table is a color ramp
between the current port's foreground color and its background color -- in most cases this means
that you get a grayscale image. (If the foreground color and background color are not black and
white, respectively, you'll get a "colorized" image.) Figure 1, which appears along with Figure 2 on
the inside back cover of this issue ofdevelop , shows an example of a once-colorful picture drawn this
GET IT TOGETHER
To display the image in its original colors, you need to somehow get the saved color table back into
the PICT before drawing. You can do this by replacing the QuickDraw low-level routine that's
called when a PixMap opcode is found in a picture. This replacement low-level routine will simply
add the color table to the PixMap and then let QuickDraw continue on its merry way, doing all the
real work of drawing, but with the correct color table in place. Replacing a low-level routine is a
void SetNewBitsProc (WindowPtr aWindow, CQDProcs *theProcs)
// Load structure with the standard routines.
// Change the one we want to override.
theProcs->bitsProc = NewQDBitsProc(AddClutProc);
// Set our window's port to use them.
aWindow->grafProcs = theProcs;
Our replacement routine first saves the contents of the PixMap's pmTable field so that it can later
restore this value before returning. It then puts a handle to the appropriate color table in the
pmTable field and calls StdBits to let QuickDraw do the hard work of drawing. Finally, it restores
the saved pmTable value in the PixMap. (Note that to be completely bulletproof you might want this
routine to check to see if the imageactually needs a color table -- that is, check to make sureit's an
indexed image, not direct. In our sample code weknow this routine won't get called with a direct
pascal void AddClutProc (BitMap *src, Rect *srcR,
Rect *dstR, short mode, RgnHandle msk)
// Save color table handle.
saveCTH = ((PixMapPtr) src)->pmTable;
// Put 'clut' resource.
((PixMapPtr) src)->pmTable = gSharedClut;
// Let QuickDraw do the work.
StdBits(src, srcR, dstR, mode, msk);
// Restore saved handle and return.
((PixMapPtr) src)->pmTable = saveCTH;
Once the new QDProcs are in place, you can simply call DrawPicture and the correct color table will
be inserted on the fly. Figure 2 shows the same PICT as in Figure 1, drawn with the correct color
table this time.
BUT WHAT IF . . .
The sample code illustrates the case in which the pictures are being created from PixMaps directly
and the color tables are being removed as it happens. But what if the images already exist, and they
need to be "postprocessed" in order to strip out the color tables? Using techniques similar to those
described above, it's not hard; see this issue's CD for an example.
Another common case might be this: you have a large number of pictures that among them share just
a few color tables. To deal with this, you could use a PicComment to store a number in the PICT
that will indicate which of the color tables to use for that PICT.
IS IT FOR YOU?
These techniques are probably useful only if you plan to deliver a lot of images that all use the same
color table (most likely on a CD). Stripping out the color tables may help you cram more images
onto your distribution media or fit a few more images in memory, perhaps allowing for faster redraw
(for example, when a sequence of pictures is being used for animation).
Remember that the images thus created will be seen as grayscale (or colorized) images in any
application that's not aware it needs to load a separate color table from a resource. But if you find
yourself jumping through flaming hoops to try to cram just a few more PICTs on your disk, this may
be just the trick you need.
GUILLERMO A. ORTIZ of Apple's Developer Technical Support group left on sabbatical just after completing the first draft
of this column, but before he had a chance to write a bio. He left his office chanting his favorite mind-soothing mantra,
"Nothing compensates like cash."*
DAVE JOHNSON watched in astonishment recently as a large hawk or falcon of some kind (he's not much of an
ornithologist) devoured a freshly killed dove just outside his living room window in San Francisco. Whoa. *
Thanks to Cameron Esfahani, Josh Horwich, and Don Moccia for reviewing this column. *