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 rest.

newPict = OpenPicture(&offRect);
CopyBits(srcPix, srcPix, &offRect, &offRect, 
	srcCopy, nil);
ClosePicture();

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 way.

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 standard technique:

void SetNewBitsProc (WindowPtr aWindow, CQDProcs *theProcs)
{
	// Load structure with the standard routines.
	SetStdCProcs(theProcs); 
	// 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 PixMap.)

pascal void AddClutProc (BitMap *src, Rect *srcR, 
					Rect *dstR, short mode, RgnHandle msk) 
{
	CTabHandle	saveCTH;

	// 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. *