Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!apple!vsi1!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: comp.sys.amiga Subject: Re: 24 bit color boards Message-ID: <1990Dec4.115219.15680@zorch.SF-Bay.ORG> Date: 4 Dec 90 11:52:19 GMT References: <6015@crash.cts.com> <1990Dec4.013744.10286@ncsuvx.ncsu.edu> <1990Dec4.061416.16472@uokmax.ecn.uoknor.edu> Organization: SF-Bay Public-Access Unix Lines: 56 drtiller@uokmax.ecn.uoknor.edu (Donald Richard Tillery Jr) writes: >In an article by: bobl@pro-graphics.cts.com (Bob Lindabury, SysAdmin) writes: [attribution for this part missing:] >>> Kent is correct. The HAM-E and DCTV are =NOT= 24 bit frame buffers >>> or boards. They get their color information from lookup tables or >>> some such thing. Animation with the HAM-E can only be done by flipping >>> full pages, unless you count writing your own software to create >>> animations and such. Don't be fooled by crafty advertising. If you >>> want true 24-bit, you'd best get a toaster or Firecracker. --Bob >>Not in any particular order, but: The Firecracker, as stated, >>is a true 24 bit board. At least you got _one_ thing right. The >>toaster, in sharp contrast to the publicity, is not a 24 bit >>board, as NTSC composite won't modulate to 24 bits precision >>in any case. As soon as you go composite (which the toaster always >>is) you don't have 24 bits. Likewise for DCTV - technically. >I think the point is that internally the image is represented by 24 bits. >I have to agree with Kent that that means that DCTV is indeed 24 bits (albeit >an unorthodox output method may further degrade the quality-I haven't seen it >yet so I can't vouch for that) because it creates such a signal. The composite >conversion is where the information is lost and this is in no way reflecitve >of DCTV or it's image resolution. It is indicative of a poor video method. Except that I made exactly the opposite point: just because you can output 8 each red, green, and blue bits to the D to A gun intensity controls doesn't mean you have the right to call your system "24 bit color", since that is a term of art that means that you _store_, not _emit_, three bytes of color data per pixel. Let's take this to ridiculous extremes to make a point. Imagine a board that supplies 3 bits of information per pixel - that means it can display any one of eight colors (or give away resolution to get more color, a separate issue); now take that three bits and decode it into an index in a color look up table. That table will have just eight entries, one for each possible bit pattern among the pixels. Now that doesn't put any limit on how big one of those eight entries can be, so, since there are so few of them, they won't impact the hardware price much, we can be real generous and supply 48 bits, 16 per gun. So we can get, what, 256 quadrillion odd colors out of this system, so obviously we can advertise it as a "48 bit color system", right? Except that we haven't told the customer this is still just an eight color system, and you aren't going to be able to display a picture without horrible stairstepping, no matter which eight of those 256 quadrillion colors are assigned to the eight color lookup table entries. A "24 bit color" system is a system that provides 24 separate bits for each separate screen pixel. Anything less is maliciously false advertising, because the stairstepping three byte deep pixels are designed to avoid will still be there, and the customer will (correctly) feel cheated. Kent, the man from xanth.