Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!bloom-picayune.mit.edu!athena.mit.edu!captkidd From: captkidd@athena.mit.edu (Ivan Cavero Belaunde) Newsgroups: comp.sys.mac.programmer Subject: Re: Color offscreen pixmap woes... Message-ID: <1991Apr9.193611.12552@athena.mit.edu> Date: 9 Apr 91 19:36:11 GMT References: <10972@ncar.ucar.edu> Sender: news@athena.mit.edu (News system) Distribution: na Organization: Massachusetts Institute of Technology Lines: 89 In article <10972@ncar.ucar.edu> hpoppe@ncar.ucar.edu (Herb Poppe) writes: >In article smargari@nmsu.edu (Susan >Margarit [or is it Jim - or a "Man Called Sue"]) writes: >> Question #2. Why is it that when you draw a 256 color pict >> resource into a color window, the DrawPicture routine ignores >> the color palette in the pict and uses the default palette? >There is no color palette in a PICT. Depends. There is no color palette opcode in the PICT definition, but the opcodes for PixMaps have an entry for a CLUT. Those could be used by either parsing the opcodes or patching the QDProcs. If the QDProcs are patched, you should do two passes: one with all procs except copybits set to do nothing, and copybits set to a routine that grabs and saves the CLUT of the PixMap, and the other with normal QDProcs, after setting the color table to the one extracted. This is because the PICT could contain drawing in color with primitives (lines and stuff) before the pixmap is reached, and changing the CLUT when reaching the pixmap would muck up the colors of the primitives drawn earlier. Parsing the opcodes is more straightforward, but writing a parsing routine involves a large amount of data (since each opcode may have different amount of data attached to it). Either way, however, you will have to deal with the (admittedly unlikely, but still possible) case that there is more than one pixmap in the PICT definition, each with a different CLUT. In this case the best way is probably to allocate an offscreen 24-bit or 16-bit deep pixmap, drawpicture into it, and then copybits onto the screen with the system clut active and in ditherCopy mode. >> When you paste it into the scrapbook, the scrapbook uses the correct >palette. >Sorry, it doesn't. I don't remember myself, but I believe you're right, the Scrapbook doesn't. >The Scrapbook is a DA. I would be surprised if it used the Palette Manager >at all. I suspect that (with SingleFinder) the palette that is used is >whatever is being used (or not used) by the program it is executing in. In >MultiFinder, it runs inside DA Handler. I would be surprised if DA Handler >uses the Palette Manager; after all, the Finder doesn't (in System 6.0.x >and earlier). There seems to be a misunderstanding here. There are palettes ('pltt's), which are managed by the Palette Manager, and there are color lookup tables ('clut's) managed by ColorQD/GDevice Mgr/Color Mgr/Palette Mgr. The screen display is determined by the current clut, which you can set through the device manager (by mucking with the color table attached to the graphic device's pixel map, I believe - I also believe this is not recommended for human interface reasons and possibly others, but I might be wrong). Additio- nally, color windows have palettes attached to them, which automatically kick in when they are activated (the system calls ActivatePalette). You can convert from a clut to a palette and back with a couple of Palette Manager routines whose name I forget. >> How do you get DrawPicture to use the correct palette? >(stuff deleted) >So you are left with reading through all the PICT opcodes, extracting all >the color references and building the "correct" palette. Good luck, and >when you've accomplished that please post your efforts to the net. Instant >fame and fortune will be yours (well, fame, at least). Apple, however, >will not be pleased. Quoting from Inside Mac Vol. 5-96: "The opcode >information in Table 3 is provided for the purpose of debugging >application-generated PICT files. Your application should generate and >read PICT files only by using standard QuickDraw or Color QuickDraw >routines (OpenPicture, ClosePicture)." None of these routines, however, do >what needs to be done. IM might say that, but parsing the PICT structure has long been an accepted way of extracting data from a PICT. I believe IM also says somewhere that you might want to parse a PICT in order to disassemble it and extracting a pixmap for private storage or somesuch, thereby implying that there are legit reasons for parsing PICTs. Besides, a) a bunch of real world apps do it (to extract EPSF in PicComments for example), and b) it's not absolutely necessary to parse the actual PICT data, as mentioned above: you can just patch the QDProcs (which is extremely legal). >In short, there doesn't appear to be a legal way to do this, which might >explain while one can never successfully copy/paste a color PICT between >any two given programs and get the colors one expects. Um, depends on the program. Director comes to mind when I try to paste a picture with a custom CLUT and it gives you an option to import the CLUT as well. Photoshop certainly can, as do other graphics programs. They may offer to change the palette, change the palette without asking, perform diffusion (using ditherCopy mode in CopyBits, etc). It can be done, it's just a hassle. The point is, if you *really* want to change the palette, you can. -Ivan Cavero Belaunde Visualist Digital Video Applications Corp. (DiVA) Internet: captkidd@ATHENA.MIT.EDU