rick@ucla-cs.UUCP (10/11/84)
<==== yum yum ====>
Is this net.graphics or net.boring? All, or at least most, of the other
groups have ongoing discussions. This seems to be a variant of net.wanted:
"we just got device such-and-so, does anybody know how to use it?".
I can't believe that either 1) no-one is doing any graphics work, or
2) everyone knows exactly what they are doing. So how about some discussion
going on here? Let's talk about such things as:
* what equipment you are USING, and to do what
* what kind of graphics systems are out there
* what are you doing research on
* what problems are you having
* what nifty solutions have you come up with for certain problems
* anything else you feel is appropriate
Come on people, we can be as verbose as the AIrheads can't we?
To start the ball rolling here is a semi-reposting.
I have been generating color (that's colour for you people in Canada) images
using an 8 bit color lookup table. However, I have been unable to find any
good algorithms (or even bad ones, although I have invented several TERRIBLE
ones) to allocate my precious 256 entries in the color table. 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? So, does anyone
have a way to allocate color table entries while a program is running with no
'a priori' knowledge of what the picture looks like?
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"
ps - my apologies to the people who saw a similar posting on a different
graphics bulletin board.thomas@utah-gr.UUCP (Spencer W. Thomas) (10/12/84)
In article <1556@ucla-cs.ARPA> rick@ucla-cs.UUCP writes: >I have been generating color (that's colour for you people in Canada) images >using an 8 bit color lookup table. However, I have been unable to find any >good algorithms (or even bad ones, although I have invented several TERRIBLE >ones) to allocate my precious 256 entries in the color table. 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? So, does anyone >have a way to allocate color table entries while a program is running with no >'a priori' knowledge of what the picture looks like? A student here did a pretty good dithering algorithm for taking a full color (i.e. 24 bit) image down to 8 bits. It uses a pre-allocated fixed color table (in fact, uses only 216 of the entries). It looks pretty good on a 512 display, and pretty fantastic on a 1k display (although still not as good as really having 24 bits). I could ask him if he would mind if it got posted to the net. (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).) =Spencer
adrian@eagle.UUCP (A.Freed) (10/12/84)
> <==== yum yum ====> > > Is this net.graphics or net.boring? All, or at least most, of the other > groups have ongoing discussions. This seems to be a variant of net.wanted: > "we just got device such-and-so, does anybody know how to use it?". > I can't believe that either 1) no-one is doing any graphics work, or > 2) everyone knows exactly what they are doing. So how about some discussion > going on here? Let's talk about such things as: > * what equipment you are USING, and to do what > * what kind of graphics systems are out there > * what are you doing research on > * what problems are you having > * what nifty solutions have you come up with for certain problems > * anything else you feel is appropriate > Come on people, we can be as verbose as the AIrheads can't we? > I am interested in the following things: How does one write PORTABLE applications for bit-mapped systems What is a good set of windowing primitives that could be implemented on any system with rastop, lines, circles, layers and textures? Does anyone have any good CAD tools for the design of graphical user interfaces? I subscribe to the mac groups and the human factors groups as there is no interesting discussion on this group. > I have been generating color (that's colour for you people in Canada) images > using an 8 bit color lookup table. However, I have been unable to find any > good algorithms (or even bad ones, although I have invented several TERRIBLE > ones) to allocate my precious 256 entries in the color table. 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? So, does anyone > have a way to allocate color table entries while a program is running with no > 'a priori' knowledge of what the picture looks like? > > > 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" > > ps - my apologies to the people who saw a similar posting on a different > graphics bulletin board. *** REPLACE THIS LINE WITH YOUR MESSAGE ***
rick@ucla-cs.UUCP (10/15/84)
<=== 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"
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (10/16/84)
We have solved a similar problem (allocation of a limited number of
color table values to points in a large color space) in our UNIX
plot interactive 3-D color display driver for the Megatek 7255.
Interested parties should contact Gary Moss <moss@brl-vld.arpa>
{decvax,esquire,seismo}!brl-bmd!moss (UUCP).gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (10/18/84)
> So, a question: do you actually have the disk storage to save lots of 24 > bit images? The fellows at Utah will probably also respond, but just in case: Typical frame buffer images are quite amenable to various data compression schemes; a typical one is Run-Length Encoding (at BRL, we picked up on what Utah had done for this and store all our frame buffer images as RLE files). I am convinced that simple RLE of R,G,B components (which shrinks images to maybe 30% of their original size) is nowhere near optimal encoding so far as size is concerned, but it has that advantage of being sufficiently fast that the time taken to unencode and display such a file is acceptable. I did the simple experiment of applying Huffman encoding (byte-wise, using "pack") on already RLE-encoded files and got a nontrivial amount of extra compression, although unpacking time was no longer negligible. I would like to hear about image file shrinking schemes that unpack quickly and have high compression.