Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!rutgers!att!pacbell.com!tandem!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: comp.sys.amiga Subject: Re: 24 bit color boards Message-ID: <1990Dec5.133018.9647@zorch.SF-Bay.ORG> Date: 5 Dec 90 13:30:18 GMT References: <1990Dec4.061416.16472@uokmax.ecn.uoknor.edu> <1990Dec4.115219.15680@zorch.SF-Bay.ORG> <1990Dec4.155412.23755@cunixf.cc.columbia.edu> Organization: SF-Bay Public-Access Unix Lines: 62 es1@cunixb.cc.columbia.edu (Ethan Solomita) writes: > xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >> 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. > Kent, take out a calculator and do a little math. The resolution of > DCTV is somewhere around 600x300, or 180,000 pixels. Give me a little credit, OK? I helped write two of the international computer graphics standards, GKS and CGM. > Therefore, if you get 18 bits worth of distinct colors out of a 24 bit > palette, you essentially have a 24 bit frame-buffer within the given > resolution limit. It's been a little while, but the last time I looked, the length limit of a color look up table was between 2^11 and 2^12 bits, not 2^18. A color lookup table is an associative memory, and 2^12 bits is about as deep a fanout as you can search before you've run out of time to paint that pixel. Moreover, if you're going to have "18 bits of color" in that table, i.e., 2^18 simultaneously displayable colors, you're going to have 2^18, 24 bit entries. Might as well just use 2^18 24 bit pixels instead, it's a lot cheaper and faster. > Ie there are only enough pixels to display 18 bits worth of color. I > believe that someone said that DCTV was the equivalent of 22 bit > planes, which exceeds that. There are only 2^18 pixels, but you still need 2^24 possible colors for them to avoid Mach bands being perceived by the more sensitive half of the population. Since you can't afford a lookup table to get those bits, you need to store one set with each pixel. You're confusing simultaneous colors with possible colors; the visual artifacts are related to possible colors, not to simultaneous colors. Said another way, to how close two colors can be (in tone) to one another, not to how many are seen on the screen. > Of course, that doesn't justify them calling it true 24 bit, but if we > are discussing usability and quality of the product (as opposed to the > advertising), it is an excellent product. As to the quality of the > ouutput signal, however, I have no idea. Nor I, nor anyone else who's not seen it. My original, and continuing, objection is to co-opting a computer graphics term with a specific technical meaning and using it in an advertisement where it is technically false to fact, and therefore misleading to the customers, and to do it with malice aforethought, since anyone doing a board design in the industry has long ago learned what the term means. It's roughly the equivalent of quoting disk drive speeds in megaBITS and abbreviating it MB for the ad, when the potential customers reading the add have long ago learned to measure data volume, and use that abbreviation, to mean megaBYTES: deliberately false and misleading advertising. Kent, the man from xanth.