Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!rpi!uupsi!grebyn!ckp From: ckp@grebyn.com (Checkpoint Technologies) Newsgroups: comp.sys.amiga Subject: Re: Better Amiga Graphics and HDTV Summary: How to arrange the color palette Message-ID: <20420@grebyn.com> Date: 17 Jul 90 01:52:00 GMT References: <3484@crash.cts.com> <1990Jul13.144616.21100@pmafire.UUCP> <285@cbmger.UUCP> Reply-To: ckp@grebyn.UUCP (Checkpoint Technologies) Organization: Grebyn Timesharing, Vienna, VA, USA Lines: 28 In article <285@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >In article <1990Jul13.144616.21100@pmafire.UUCP> seh@pmafire.UUCP (Steve Holaday) writes: >>BTW the pallet should only needs to be large >>enough to display 1 million pixels (2^20 or less). This will allow each >>pixel of a 1024 by 1024 display to be a different color. > >Er, if you store 24 or 32 bits per pixel, you simply don't need any >palette! But your argument sounds interesting: If you can afford to >limit yourself to 1 mio pixels then only 10 bit per pixel would again >be sufficient, cutting memory consumption by a factor of 2 to 3. >But would that be worth the new limitations? That color palette would be a million entries of 24 bits each, meaning three million bytes of 4ns color palette RAM. For some strange reason, this sounds very expensive to me... Actually, if you're going to do 24 bit pixels, then I'd suggest something like three palettes of 256 entries each, a palette each for three 8 bit pixels, mixed together for the final image. I wouldn't want to lose the color palette entirely on 24 bit pixels; there's some value to remapping colors without rewriting the pixels, for many applications that aren't basic image processing. -- First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / \\ / / Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o Now for the witty part: I'm pink, therefore, I'm spam! \/