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