crunch@well.sf.ca.us (John Draper) (08/31/90)
We are having some problems in dealing with CLUT+s. We are developing software
(A TV Board) which has to fill in a CLUT by hand in order to meet our stringent
performance needs (Live Video). In page 145 in IM Vol 5, in the description of
the "RestoreEntries" call, the 3rd paragraph mentions "this may cause RGBForeColor
to act strangely". Is there a Tech note that describes this problem, and how
do I get around it, because it certainly does what the manual says
(IE: Act strangley). Below is a sequence of calls which we do to change it.
We would appreciate some enlightenment from you Gurus on this matter, or
some way we can get around it.
myTab = GetCTable(id); /* Get a color table from a resource */
for (i=1; i<257; i++)
selection[i] = i; /* Build up a ReqListRec as outlined in IM */
/* Determine which PIX depth to use */
selection[0]J= (pix_depth == 8) ? 254 : 14;
/* Now call ColorQD function with NULL to use CURRENT devices color table */
RestoreEntries(myTab, NULL, &selection[0]);
/* Next we get the GDevice PixMap */
gd = GetDevice();
pm = (**gd).gdPMap;
/* Now change the ctSeed field to force the update */
(**(**pm).pmTable).ctSeeid;
/* Now call an un-documented function call */
CTabChanged((**pm).pmTable);
NOTE: The un_documented call above comes from a document released by Apple
and isn't in IM Vol 5. We understand the ramifications of doing this, but
would like a workaround if possible.
/* Next we notify that the table has been changed by calling yet another
un-documented Color QD call. (Tsk Tsk!!)
*/
GDeviceChanged(gd);
/* And mow we make our Inverse table */
MakeITable(myTab, (**gd).gdITable, 0);
/******* End of code segment *******/
So, this is what we do. Please take your time and check with your Guru's
to see what we might have overlooked.
Thanx....
John D.
Berlin, W. Germany.
Please reply to: crunch@well.sf.ca.us
I can pick up my Email from Germany.tim@hoptoad.uucp (Tim Maroney) (09/03/90)
I don't have an answer to this. Neither, apparently, does anyone else. This has happened quite a few times lately with a number of questions about color tables and such. Couldn't Apple dispatch some helpful soul who knows about Color Quickdraw to answer the many strange questions that come up when using it? For instance -- I'm drawing files (PICT and TIFF) into 32-bit offscreen pixmaps, then drawing them to eight-bit screens. The amount of color distortion is phenomenal, although the files look great on a 32-bit screen. It's so bad that it seems the system is not even getting mileage out of the 256 colors in the CLUT -- it seems to be making bad selections. What do I need to do? Is there some magic color table bit I should set? Should I somehow increase the bits in the inverse table for the monitor? Should I draw back to a magic depth-zero offscreen pixmap before dumping to the screen? Does the unused byte of each pixel have to have some particular value? How can I get a handle on what is causing the problem? -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com If you vote for clowns, you have no right to complain that only clowns make it to the ballot.
pepke@gw.scri.fsu.edu (Eric Pepke) (09/05/90)
In article <20089@well.sf.ca.us> crunch@well.sf.ca.us (John Draper) writes: > We are having some problems in dealing with CLUT+s. We are developing software > (A TV Board) which has to fill in a CLUT by hand in order to meet our stringent > performance needs (Live Video). In page 145 in IM Vol 5, in the description of > the "RestoreEntries" call, the 3rd paragraph mentions "this may cause RGBForeColor > to act strangely". Is there a Tech note that describes this problem, and how > do I get around it, because it certainly does what the manual says > (IE: Act strangley). The reason RGBForeColor behaves strangely is that RestoreEntries does not reset the inverse table, which is used by RGBForeColor to get close to the correct color. You have to make a new inverse table using MakeITable, which is described on page 142. Of course, then you've got to stick it in the gDevice. I use an offscreen gDevice with offscreen 8-bit pixmaps, which are filled using Color2Index. I CopyBits the pixmaps onto the screen into a window with palettes the same as the desired color table, all tolerant colors with a tolerance of 0. It works fine. Apple's quantization scheme is OK but not perfect. If you want to, you can write your own search procedure. All the really good ones are slow. Eric Pepke INTERNET: pepke@gw.scri.fsu.edu Supercomputer Computations Research Institute MFENET: pepke@fsu Florida State University SPAN: scri::pepke Tallahassee, FL 32306-4052 BITNET: pepke@fsu Disclaimer: My employers seldom even LISTEN to my opinions. Meta-disclaimer: Any society that needs disclaimers has too many lawyers.
russotto@eng.umd.edu (Matthew T. Russotto) (09/06/90)
In article <12230@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: > >For instance -- I'm drawing files (PICT and TIFF) into 32-bit offscreen >pixmaps, then drawing them to eight-bit screens. The amount of color >distortion is phenomenal, although the files look great on a 32-bit >screen. It's so bad that it seems the system is not even getting >mileage out of the 256 colors in the CLUT -- it seems to be making bad >selections. As I understand it, CQD in fact makes NO selections-- it uses the colors available in the CLUT. You have to pick good colors in the first place.