gsarff@sarek.UUCP (Gary Sarff) (01/17/90)
Several people here have made the statement that the BlackBelt video unit's REG and HAM-E modes are not IFF or violate IFF or some such and are therefore bad. 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. Also, the color registers that the new modes use are in subsequent scan lines of the _BODY_. This has nothing to do with any of the other hunks in the IFF file which determine viewmodes, pagesize, etc. Are you people saying that certain pixel combinations in a body are illegal? This sounds like nonsense to me, since 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. IFF parsers don't look inside the body hunk to see what pixels are there anyway, so how is this not conforming to "standard IFF"?? Comments from BlackBelt welcome too. ---------------------------------------------------------------------------- "I Am The Reincarnation of Abraham Lincoln", Claims Jim Bakker. --An Enquirer Exclusive Iranian Brain Boffs produce Crazed Mutant Telekinetic Kitten Girl --See story inside Only in America!
jeh@elmgate.UUCP (Ed Hanway) (01/20/90)
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 <std_disclaimer.h> jeh@elmgate.UUCP
tron1@tronsbox.UUCP (HIM) (01/22/90)
>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? No. At the momentr it will have to be , but it is MUCH more useful to write IFF files that follow normal guidline (break the pallet out to a pallet chunk and so on. **************************************************************************** Everything I say is Copr. 1990, except the stuff I stole from someone else and the stuff I don't want responsibility for. Kenneth J. Jamieson: Xanadu Enterprises Inc. "Professional Amiga Software" UUCP: tron1@tronsbox.UUCP BEST PATH ---> uunet!tronsbox!tron1 Sysop, Romantic Encounters BBS - (201)759-8450 / (201)759-8568 ****************************************************************************
olsen@hpfcdq.HP.COM (John Olsen) (01/23/90)
>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_. jeh@elmgate.UUCP (Ed Hanway) writes: >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. How about removing the IFF/non-IFF debate entirely by making programs read 24 bit/pixel files (already standard) and write HAM-E into memory. When you save the picture, write it back out as a 24 bit/pixel file again. Any program that can handle 24 bit/pixel can then chew on the image without caring a single whit whether the owner wants to display it on a custom frame buffer or a Black Belt box. It still means modifying all those paint programs to know about the BB box, and making them know how to read and write 24 bit/pixel files, but the argument about file formats and specs goes away. The color table cookies only exist while the image is in memory. Comments? Flames? Money?
ln63wkp@sdcc4.ucsd.edu (The Priss) (01/23/90)
In article <4710008@hpfcdq.HP.COM> olsen@hpfcdq.HP.COM (John Olsen) writes: >How about removing the IFF/non-IFF debate entirely by making programs read >24 bit/pixel files (already standard) and write HAM-E into memory. When you >save the picture, write it back out as a 24 bit/pixel file again. Any >program that can handle 24 bit/pixel can then chew on the image without >caring a single whit whether the owner wants to display it on a custom frame >buffer or a Black Belt box. >Comments? Flames? Money? Yeah that would be nice except that 24 bit files can get quite large. I like the idea of storing an image at it's maximum resolution for future generations, but, you can only store so many huge 24 bit files in a small 40Mb HD (like mine). Besides, the conversion step may be slow and that effect you want to avoid when running slideshows, etc. -Viet vho@ucsd.edu Please don't flame me!:-(
kudla@pawl.rpi.edu (Robert J. Kudla) (01/24/90)
In <6399@sdcc6.ucsd.edu> ln63wkp@sdcc4.ucsd.edu (The Priss) writes:
-> Yeah that would be nice except that 24 bit files can get quite
-> large. I like the idea of storing an image at it's maximum
-> resolution for future generations, but, you can only store so many
-> huge 24 bit files in a small 40Mb HD (like mine). Besides, the
-> conversion step may be slow and that effect you want to avoid when
-> running slideshows, etc.
No flames, just an observation....
Ham-E pictures are currently (or will be, anyway) stored as hi-res
4-bitplane pictures. But the picture itself (after Black Box gets done
with it) is low-res, and only the palette is 24-bit to begin with (the
picture is 8-bit). What's the difference space wise between a
640-across 4-bit picture and a 320-across 8-bit picture with 64 extra
bytes of color information? They'll compress to basically the same
size....
--
Robert Jude Kudla <kudla@pawl.rpi.edu>
"Famous? I'm not famous. People come up to me after a show and say
'Hey, Steve!'"
-Jon Andersonifarqhar@mqccsunc.mqcc.mq.OZ (Ian Farquhar) (01/24/90)
In article <6399@sdcc6.ucsd.edu> ln63wkp@sdcc4.ucsd.edu (The Priss) writes: > >Yeah that would be nice except that 24 bit files can get quite >large. I like the idea of storing an image at it's maximum >resolution for future generations, but, you can only store so many >huge 24 bit files in a small 40Mb HD (like mine). Besides, the >conversion step may be slow and that effect you want to avoid when >running slideshows, etc. > So, why don't we define a few new compression standards. The currently implimented one is a simple run length encoding system that exploits scan coherence. What I would like to do is support area coherence. Suggestions, anyone? Oh look, here comes the new, revised and spellchecked signature... Close that door, you're letting reality in! +-----------------------------------+-------------------------------+ | Ian Farquhar | Phone : (02) 805-7420 (STD) | | Microcomputer Support | (612) 805-7420 (ISD) | | Office of Computing Services | Fax : (02) 805-7433 (STD) | | Macquarie University NSW 2109 | (612) 805-7433 (ISD) | | Australia | Also : 805-7205 | +-----------------------------------+-------------------------------+ | ACSNet ifarqhar@macuni.mqcc.mq.oz | | ifarqhar@mqccsuna.mqcc.mq.oz | +-------------------------------------------------------------------+ D