Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think!snorkelwacker!mit-eddie!uw-beaver!zephyr.ens.tek.com!tektronix!psueea!jove.cs.pdx.edu!bartonr
From: bartonr@jove.cs.pdx.edu (Robert Barton)
Newsgroups: comp.sys.amiga
Subject: HAM-E not compatible with ILBM?
Message-ID: <2251@psueea.UUCP>
Date: 22 Jan 90 12:51:07 GMT
Sender: news@psueea.UUCP
Reply-To: bartonr@jove.cs.pdx.edu (Robert Barton)
Organization: Dept. of Computer Science, Portland State University; Portland OR
Lines: 16


 gsarff@sarek.UUCP (Gary Sarff) writes:
> In what way does a HAM-E picture not adhere to IFF?  The "magic cookie" is a
> series of specific pixel values, _BUT_ it is in the _BODY_ hunk of the IFF
> file that this will appear.
    
  You might want to try checking the IFF documentation on ILBMs some time.  It's
in the "Includes & Autodocs" manual.  Under BODY it states: "The source raster
is stored in a 'BODY' chunk" and "The BODY's content is a concatenation of scan
lines".  No mention of cookies, magic or otherwise.
  
>  Also, the color registers that the new modes use are in subsequent scan lines
> of the _BODY_.
  
  No mention of storing color register data in the BODY either.  That's what a
CMAP chunk is for.