Path: utzoo!utgpu!watserv1!watmath!att!pacbell!pacbell.com!ucsd!sdd.hp.com!uakari.primate.wisc.edu!ark1!oasys!mimsy!mojo!russotto
From: russotto@eng.umd.edu (Matthew T. Russotto)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Palette Manager Woes...HELP!
Message-ID: <1990Sep6.211354.6340@eng.umd.edu>
Date: 6 Sep 90 21:13:54 GMT
References: <3cR602lw02Cj01@JUTS.ccc.amdahl.com>
Sender: news@eng.umd.edu (The News System)
Organization: College of Engineering, Maryversity of Uniland, College Park
Lines: 51

In article <3cR602lw02Cj01@JUTS.ccc.amdahl.com> rla20@DUTS.ccc.amdahl.com (Roger Allen) writes:
>Currently, I am working on my own Gif viewer.  Mostly it is for my own
>personal enjoyment (agony) but if I can get this @#$%&* thing to work
>maybe I will make it a shareware product in an already packed market.
>
>ANYWAY, I am having a frustrating time with the palette manager and
>getting the correct colors on the screen.  I've read the IM V PM Chapter,
>I've read all the c.s.m.p items that seemed relevant and I'm still
>confused.  Does Apple have a document written so mere humans can
>understand the Palette Manager?

No.  You have to have an IQ of at least 300, like all Apple technicians :-)
(the company average IQ is within reason thanks to management and marketing)

>So, here is what the program is doing:
>
>    1. Read in all the Gif header stuff and set up a Palette of all
>       the colors that the image needs. (pmTolerant, 0 tolerance--I
>       tried pmExplicit & pmAnimated to no avail)

pmExplicit is wrong, though pmExplicit+pmTolerant under 32-bit quickdraw would
simplify things somewhat-- but don't do it, it is unfriendly to ask for
specific entries. pmTolerant, 0 tolerance is correct.

>    2. Open up a window that the image will go into, attach the Palette
>       and activate it.
Right.

>
>    3. Now, here is the tricky part...
>       Read in the gif picture data and store it in an off-screen
>       bitmap.  BUT, each gif data byte is really an index into
>       its own CLUT (the palette I spoke of), it is not a RGB value.

No big deal.  What you do is make a translation table between the gif values
and the actual pixel values as assigned in the offscreen buffer.  I.e.
make your offscreen buffer with a copy of the device color table and do a
for (i=0; i < numcolors; i++)
	trans[i] = Color2Index(&gifpal[i]);

Where gifpal is an array of RGB colors derived from the GIF color tables.

Then, before you stuff the data in, run it through trans, thus:
*(baseaddr + x + y * rowbytes) = trans[gifdatabyte];

The other method, very easy if you use the new 32-bit quickdraw routines
documented in d e v e l o p issue 1, is to set up a NewGWorld with a color
table derived from the GIF palettes.  Then just stuff the raw data to the
buffer, SetGWorld appropriately, and, you have it.  (screen updates are slower
this way, but there are some other advantages).  I refer you to that issue
of develop for more info.