dmb@wam.umd.edu (David M. Baggett) (04/04/91)
hyc@hanauma.jpl.nasa.gov (Howard Chu) writes (in response to John Logajan): >>My guess would be that flicker and pseudo-shadow movements would be >>quite severe. So how does it really look? > >Try it and see, eh? }-) The color scheme I chose above gives the >entire 256 color palette of the PC w/VGA. Try other setups.... I did try out the Fractint you posted ages ago that used flicker palettes, and it didn't flicker too badly. I bet some of the combinations you'll get with the two palettes you posted are pretty terrible though. I've played with this technique several different times and have never really been satisfied with the results. I'll load up my animation editor and try out color combinations at 60Hz -- some combinations seem to "fuse," i.e,. blend perfectly. In these cases you simply cannot tell that it's swapping between two colors. In many other cases, however, the colors don't fuse at all, and you get horrible, headache-inducing flicker. Mixing 000 and 777, e.g., is totally unbearable, at least on my monitor. I made a little demo that just mixed all combinations of colors in the default NEOchome palette. I got 256 colors on the screen. Yup. But you had to look at it from across the room, with the contrast all the way down, and squinting, or your eyes would turn to jelly and ooze out your head. (Neither was a pretty sight.) :-) I tried to come up with a formula or set of criteria that would predict which colors would fuse and which would flicker, but never could see a pattern. I did notice that some combinations look OK if the "blending area" is small, but not when you swap, e.g., two solid-color screens. In general, the larger the area, the more flicker. I also wonder if it's monitor-dependent. Anybody know how to algorithmically pick colors that always blend? Given such an algorithm, one could write a program to find an "optimal flicker palette" -- one where the most combinations possible were rock-solid. This would yield more colors on the screen at once with little flicker and not much CPU overhead. As Howard pointed out, such a screen mode would be superior to Spectrum 512 because each of the N different colors could appear anywhere on the screen. You could probably even do interactive animation (read: GAMES) with this mode, although all your raster operations would be only half as fast. Even if you couldn't find two palettes in which all combinations blended, finding enough to get 32 solid combinations would be better than what we've got now: 16 colors, Spectrum 512, or brain-melting flicker. Maybe if we assigned everyone reading this newsgroup a color combination to try and compiled the results... (Heck, there are only 262,144 different combinations. Aren't there supposed to be tens of thousands reading this group? Well then, that's only, what, 10-20 per person? I'll start the ball rolling with 000 and 001...) Dave Baggett dmb%wam.umd.edu@uunet.uu.net
micro@imada.dk (Klaus Pedersen) (04/05/91)
dmb@wam.umd.edu (David M. Baggett) writes: >Anybody know how to algorithmically pick colors that always blend? >Given such an algorithm, one could write a program to find an "optimal >flicker palette" -- one where the most combinations possible were >rock-solid. You can try to pick colors that have aprox. the same intensity. To this you can use the NTSC formular : Luminosity = 0.299*Red + 0.587*Green + 0.114*Blue I have some code at here that can display 256 graylevels on the mono screen. (written in C). The program is less than 50 lines long, and features an advanced errordiffusion ditering algoritm, with a small edge sharping filter (simple laplace). This have been coupled with a 3 screen 'flicker' mode. The result is approx. the same as 256 grayscale VGA LCD screens (I think mine is better, because there is no shadows running around the screen, but...) The 3 screens is build to that the 'on' pixels is equally distributed on the 3 'planes' - this avoids flicker. All this could used with color too, and I think the result would be even better because you can pick colors which is closer to each other (than on and off)... In color mode you can probaly show true-color, but you will need to make some additional code, to handle interesting subjets - such as picking reprensative colors from the picture file... The program IS quick hack, and therefor it only runs on mono in 640x400. I will send the source to who-ever that is interested... Klaus (micro@imada.dk)
warwick@cs.uq.oz.au (Warwick Allison) (04/05/91)
In <1991Apr4.052519.9240@wam.umd.edu> dmb@wam.umd.edu (David M. Baggett) writes: >Anybody know how to algorithmically pick colors that always blend? Colours with a similar lumminance will blend fine. >Maybe if we assigned everyone reading this newsgroup a color combination >to try and compiled the results... (Heck, there are only 262,144 different >combinations. Aren't there supposed to be tens of thousands reading >this group? Well then, that's only, what, 10-20 per person? I'll start >the ball rolling with 000 and 001...) Hmm, let's see, two palettes of 16 colours, each colour has 512 choices. That's 512 to the power of 32. Which is the measley small value of 497323236409786642155382248146820840100456150797347717440463976893159497012533375533056 different palette pairs, less equivalent pairs. okay, I'll do 2 and 3. :-) No, but I'll check out the technique a bit more, using the pallette described in the fractint post. Warwick. -- _--_|\ warwick@cs.uq.oz.au / * <-- Computer Science Department, \_.--._/ University of Queensland, v AUSTRALIA.
eahsnsr@nmt.edu (Eric A. Hobbs) (04/05/91)
In article <1991Apr4.223506.11715@imada.dk> micro@imada.dk (Klaus Pedersen) writes: [stuff deleted] > >I have some code at here that can display 256 graylevels on the mono screen. >(written in C). The program is less than 50 lines long, and features >an advanced errordiffusion ditering algoritm, with a small edge sharping >filter (simple laplace). This have been coupled with a 3 screen 'flicker' >mode. The result is approx. the same as 256 grayscale VGA LCD screens (I >think mine is better, because there is no shadows running around the screen, >but...) >The 3 screens is build to that the 'on' pixels is equally distributed on the >3 'planes' - this avoids flicker. >All this could used with color too, and I think the result would be even >better because you can pick colors which is closer to each other (than on and >off)... >In color mode you can probaly show true-color, but you will need to make some >additional code, to handle interesting subjets - such as picking reprensative >colors from the picture file... > >The program IS quick hack, and therefor it only runs on mono in 640x400. >I will send the source to who-ever that is interested... > >Klaus (micro@imada.dk) Wow! Now if only someone would write a mono GIF viewer with this!!! <Hint> <Hint> <Hint> :-) I would if I knew how to program!!! ------------ Eric A. HOBBS! eahsnsr@JUPITER.nmt.edu