Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!bbn!rochester!kodak!elmgate!jeh From: jeh@elmgate.UUCP (Ed Hanway) Newsgroups: comp.sys.amiga Subject: Re: HAM-E not IFF?? Summary: IFF's aren't just for Amigas any more Message-ID: <1191@elmgate.UUCP> Date: 19 Jan 90 21:29:36 GMT References: <00363@sarek.UUCP> Sender: jeh@elmgate.UUCP Reply-To: jeh@elmgate.UUCP (Ed Hanway) Organization: Eastman Kodak Company, Rochester, NY Lines: 33 In article <00363@sarek.UUCP> gsarff@sarek.UUCP (Gary Sarff) writes: >In what way does a HAM-E picture not adhere to IFF? ... >... the color registers that the new modes use >are in subsequent scan lines of the _BODY_. But any program reading the file would have to recognize the Black Belt cookie in the body to know that these are the "real" color registers, not the ones in the color map. >...any properly functioning IFF parser is >going to be able to parse these new HAM-E pictures just fine and if it >attempts to display them on the amiga screen, using the information in the >IFF header hunks, it will display as HAM-E. There are many things you can do to an IFF file other than just display it on an Amiga screen. Suppose I want to run a 256-level gray scale picture through some image manipulation software to quantize it down to 16 gray levels. Should the software be rewritten to recognize the Black Belt cookie, (and, later on, the NewTek cookie, ...) or should it be written to accept standard IFF files with an arbitrary number of bit planes and palette size? I don't see anything wrong with producing Black Belt files with everything embedded in the body. After all, it lets you use a lot of existing software, especially slide show programs, etc. But if/when software is rewritten to support the Black Belt gizmo, I'd at least like to see an option to produce 8 bitplane, 256 color IFF files. Who's to say that there won't someday be an Amiga that'll fully support 8 (or more) bit planes? --- Ed Hanway Eastman Kodak Company ...!rochester!kodak!elmgate!jeh #include jeh@elmgate.UUCP