Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site ucla-cs.ARPA Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!sdcrdcf!trwrba!cepu!ucla-cs!rick From: rick@ucla-cs.UUCP Newsgroups: net.graphics Subject: Re: boring group Message-ID: <1651@ucla-cs.ARPA> Date: Mon, 15-Oct-84 13:09:40 EDT Article-I.D.: ucla-cs.1651 Posted: Mon Oct 15 13:09:40 1984 Date-Received: Wed, 17-Oct-84 06:16:42 EDT References: <1556@ucla-cs.ARPA> <1206@utah-gr.UUCP> Organization: UCLA CS Dept. Lines: 44 <=== yum yum ===> From: thomas@utah-gr.UUCP (Spencer W. Thomas) > >In article <1556@ucla-cs.ARPA> rick@ucla-cs.UUCP writes: >> Of course it >>would be a lot easier to generate the picture completely in 24 bits but then >>what is the point in using a scanline algorithm for rendering? > . . . > >(I don't understand the comment about 24 bits above - we do all our >scanline rendering in 24 bits (of course, we have 24 bit frame buffers).) > Hmmmmm, I wrote that comment but damned if I can remember what I was talking about. Maybe I was asleep at the time. Actually, I think what I meant to say was that we use scanline algorithms, at least partially, so that we don't need to have an entire copy of the frame buffer in memory at any time. If you render in 24 bits but don't have 24 bit frame buffer then you either convert your 24 bits to whatever size you have while the renderer runs or save the entire image somewhere (perhaps a disk file). If you save the entire image then you lose *part* of the advantage of using a scanline algorithm. So, a question: do you actually have the disk storage to save lots of 24 bit images? What kind of resolution? Must be nice to get that kind of support from your department; UCLA is not particularly supportive of graphics. Finally, I actually got some references for allocating color table entries: (1) Paul Heckbert "Color Image Quantization for Frame Buffer Display" Computer Graphics vol.16 number 3 (Siggraph 82 preceedings) pp297-307 (2) A.F.Leher and R.J.Stevens "High-Speed Manipulation of the Color Chromaticity of Digital Images" IEEE Computer Graphics and Applications vol.4 number 2 (Feb. 1984) pp 32-39. Don't know how I missed the first one, and haven't gotten around to the second one. So much for "research".:-) Rick Gillespie rick@ucla-cs ...!{cepu|ihnp4|sdcrdcf|ucbvax}!ucla-cs!rick "I came here for a good argument!" "No you came here for an argument"