hpoppe@bierstadt.ucar.edu (Herb Poppe) (08/01/89)
I'm starting my first Color Quickdraw application. I think I understand the process of creating graphics in a color window: setting up the color environment with the Color Picker Package and the Palette Manager and then drawing with the selected colors after calling PMFore(Back)Color, etc. However, I don't understand how to handle PICTs read from the Clipboard or a file. How does one set up the palette for the window in which the picture will be displayed before DrawPicture is called such that one sees the same colors on screen as when the picture was created? There don't seem to be any PICT opcodes that set the palette dynamically as the picture is being processed by DrawPicture. Applications like Powerpoint don't copy the 'pltt' resource to the Clipboard and there is no place in a PICT file for one. I can't seem to find a reference to an appropriate technique in IM-V or the TN or Q&A stacks. I'm stumped. Would someone please enlighten me? Herb Poppe NCAR INTERNET: hpoppe@ncar.ucar.edu (303) 497-1296 P.O. Box 3000 CSNET: hpoppe@ncar.CSNET Boulder, CO 80307 UUCP: hpoppe@ncar.UUCP
dfs059@ipl.jpl.nasa.gov (Dan Stanfill) (08/10/89)
hpoppe@bierstadt.ucar.edu (Herb Poppe) asks how to get the palette for
a PICT before drawing it with DrawPicture.
I also struggled with this problem for a while, before I came up with
the following (very ugly) solution. I thought my solution was pretty
weird, but I was quite happy when I found out that the folks at NCSA
use the exact same technique. If anyone knows a better technique,
please post it!
This technique applies to disk files, but could be extended to the
clipboard as well.
The secret is to use SetStdCProcs() to intercept calls to CopyBits(). I
use the spooling technique described in IM-V as well, so my code looks
like the following:
SetStdCProcs(&myProcs);
dstPort->grafProcs = (QDProcsPtr) &myProcs;
myProcs.getPicProc = (Ptr)ReadPictData;
if (srcPort == dstPort)
myProcs.bitsProc = (Ptr)MyCopyBits; /* only for screen updates */
srcPort and dstPort are a bit of weirdness I use to check whether or not
I am printing. Note that if you spool from disk you should use a buffering
scheme to read in the pict file in a big chunk in ReadPictData(), otherwise
it will be excruciatingly slow. You can then write MyCopyBits() to look
something like the following:
/************************************************************************/
pascal void MyCopyBits(srcBits, srcRect, dstRect, mode, maskRgn)
PixMapPtr srcBits;
Rect *srcRect, *dstRect;
short mode;
RgnHandle maskRgn;
{
PaletteHandle pal;
CGrafPtr dstPort;
CTabHandle ctab;
GetPort(&dstPort);
pal = GetPalette(dstPort); /* check to see if palette already exists */
if (pal == NIL)
{
ctab = srcBits->pmTable;
if (ctab != NIL)
{
pal = NewPalette(256, ctab, pmTolerant, 0);
FreeSomeColors(pal);
SetPalette(dstPort, pal, TRUE);
ActivatePalette(dstPort);
}
}
StdBits(srcBits, srcRect, dstRect, mode, maskRgn);
return;
}
/************************************************************************/
FreeSomeColors() is my own routine to keep any window from sucking up all
256 colors (this allows color menus, desktops, etc., to still look ok).
Finally, after your call to DrawPicture(), be sure to reset the std procs:
dstPort->grafProcs = NIL;
The code above has a flaw; if a picture has more than one CopyBits call
with more than one palette, only the first one is used. I find that
most of the time that is ok, though. The only problem I have had is with
the output from some scanner software, which, being pre-32-bit-quickdraw,
draw 24 bit data as a series of three CopyBits with red, green, and blue
ramps, respectively. If your pict file is a 32 bit pict, you won't get
a color table, so you ought to handle that as well. The default palette
works reasonably when you don't have any knowledge of the color content of
an image.
Good luck!
Dan Stanfill
Visualization and Earth Sciences Applications Group
Image Processing and Applications and Development Section
Jet Propulsion Laboratory
dfs@flower.jpl.nasa.gov
dan@dial.jpl.nasa.gov
dfs059@ipl.jpl.nasa.gov