mwp@cs.mu.oz.au (Michael Paddon) (05/15/89)
I have some 8-bit color bitmaps I would like to display under NeWS (via the readcanvas routine). It appears, however, that the NeWS colormap is static and that readcanvas just selects the closest color. Unfortunately, the closest color algorithm makes my images look interesting, but not in the way I would like. Is there any way of fiddling the colormap? It doesn't have to be particularly portable. [I am running NeWS 1.1 on a Sun 3/60 under SunOs 3.4] As a footnote, it seems that Sun were very shortsighted if there is no way to get the colors you really asked for. Lots of real world applications need just that (in particular, mine does :-). ------------------------------------------------------------- | | email: mwp@munnari.oz.au | | | voice: (03) 344 4246 | | Michael Paddon | snail: Department of Computer Science, | | | The University of Melbourne, | | | Parkville 3052, Australia | -------------------------------------------------------------
barnett@crdgw1.crd.ge.com (Bruce G. Barnett) (05/16/89)
In article <1494@murtoa.cs.mu.oz.au>, mwp@cs (Michael Paddon) writes: >As a footnote, it seems that Sun were very shortsighted if there is >no way to get the colors you really asked for. Lots of real world >applications need just that (in particular, mine does :-). The model may have a few warts, but it is a useful model in several applications: You have a true color (24-bit) system You have a black&white screen You have to share the window with 10 other applications, each with it's own color map. You ask for a thousand different colors, but only display 200 at a time, and the system can only display 256 different colors. Remember, the NeWS model is DISPLAY INDEPENDANT. The application may not be capable of displaying what you ask for, but the window server tries to display the best approximation to the color you asked for. Your applications are therefore portable to displays of a different type. -- Bruce G. Barnett <barnett@crdgw1.ge.com> a.k.a. <barnett@[192.35.44.4]> uunet!crdgw1.ge.com!barnett barnett@crdgw1.UUCP
mwp@murtoa (Michael Paddon) (05/17/89)
From article <406@crdgw1.crd.ge.com>, by barnett@crdgw1.crd.ge.com (Bruce G. Barnett): > > Remember, the NeWS model is DISPLAY INDEPENDANT. > The application may not be capable of displaying what you ask for, > but the window server tries to display the best approximation to the > color you asked for. Your applications are therefore portable to displays of > a different type. There should be a way to say "I *really* want this color", and the server will comply if possible. There is nothing device dependent about this. Fooling around with color maps directly is inferior due to the portability problems you pointed out. ------------------------------------------------------------- | | email: mwp@munnari.oz.au | | | voice: (03) 344 4246 | | Michael Paddon | snail: Department of Computer Science, | | | The University of Melbourne, | | | Parkville 3052, Australia | -------------------------------------------------------------
davidw@prlhp1.UUCP (David Walker) (05/18/89)
> >I have some 8-bit color bitmaps I would like to display under NeWS >(via the readcanvas routine). It appears, however, that the NeWS >colormap is static and that readcanvas just selects the closest >color. > We have the same problem displaying `real world' images on our sun3/60. We gave up on trying to manipulate the colour map in NeWS and went for our own picture coding software. I grabbed the NeWS clut from a header of a NeWS clut image and wroye my own software which approximated the pixel values in my pictures to those available in NeWS. This is essentially what NeWS does but in a simple way. My program uses the simplified Floyd-Steinberg algorithm which essentially passes colour approximation errors to adjacent pixels on the right, bottom, and bottom right of the pixel in question. This method gives a remarkable improvement in image quality. david walker davidw@prl.philips.co.uk
mongo@helios (Mongo Package) (05/18/89)
>I have some 8-bit color bitmaps I would like to display under NeWS >(via the readcanvas routine). It appears, however, that the NeWS >colormap is static and that readcanvas just selects the closest >color. > In order to support the X11 colormap models, X11/NeWS must allow colormap manipulation. It has some new operators to deal with this. Of course, use of these operators requires knowledge of the capabilities of the NeWS server-->It won't work on just any display. Steve Allen This is merely a repeat of words heard at the Sun New World Expo. No part of the UC would have opinions like mine.
barnett@crdgw1.crd.ge.com (Bruce G. Barnett) (05/18/89)
In article <1501@murtoa.cs.mu.oz.au>, mwp@murtoa (Michael Paddon) writes: >There should be a way to say "I *really* want this color", and the server >will comply if possible. There is nothing device dependent about this. >Fooling around with color maps directly is inferior due to the portability >problems you pointed out. I just tried an experiment, and now I understand. You are right in that NeWS 1.1 has a real problem with colors. I just now tried to create several windows with the frames of different colors, gradually changing the values. Since I only have 5 different colors at the start, I would expect that the colors I selected would be used, with a gradual changing of hue. Instead - the colors are rounded off somehow, and sudden jumps in colors are seen. I would expect that if I wanted black, white, and 200 shades of blue, I would be able to get them. I hope X/NeWS doesn't have this problem. -- Bruce G. Barnett <barnett@crdgw1.ge.com> a.k.a. <barnett@[192.35.44.4]> uunet!crdgw1.ge.com!barnett barnett@crdgw1.UUCP
gnu@hoptoad.uucp (John Gilmore) (05/19/89)
Since people seem to be interested in improving the color support
in NeWS, here is a reposting and amplification of my ideas on the subject.
The idea is to get exactly the colors you ask for, unless you ask for
too many. Most "8 bit color" framebuffers can specify up to 256 24-bit
colors. If you ask for 100 24-bit colors (by rendering something after
calling setcolor with 100 different arguments) then you should see
exactly those 100 colors on the screen. It's only if you ask for 300
24-bit colors that strange effects should occur; more below on that.
This is one area where X/NeWS moves backwards instead of forwards, due
to unimaginatively adopting the X color map model for NeWS.
John
Date: Thu Nov 3 23:37:00 1988
Subject: Re: Dithering and color maps
Newsgroups: comp.windows.news
I have some ideas on better ways to handle color maps in NeWS. Since
the color model is already 24 bit, there should be no change to applications.
What I'd like to do is have NeWS start off with an empty color map, and
add colors to it as they are imaged. This means that unless you use
more colors than your color map holds, you would always get exactly the
colors you ask for. I find it very frustrating that with the color tools,
I can slide the sliders all around and the same damn wrong color stares out
at me; or that when sliding the 'saturation' or 'brightness' slider,
the hue constantly changes.
The hard part is of course what to do if more colors are requested than
you can hold. The first is to garbage-collect; scan the screen and
throw away any colors that are no longer in use. If you have garbage
collected recently and you still have too many colors, it's time to fall
back on the old method (pick a close color to what was requested / dither
for 24-bit images) though we can probably do better by picking a color
map that concentrates on the colors the user is actually using at the moment.
For example, if there are no greens but seventy shades of yellow, maybe
give them 40 shades of yellow and no greens.
If you have to 'reclaim' colors that were in use, canvases which were
using those color values become damaged and must repaint. This may
cause applications a little trouble if they don't expect damage (e.g.
if retained), though all applications 'should' always be willing to
repair damage. Judicious choice of which colors to replace with which
others should minimize the amount of wierd colors shown on the screen
before the damage is repaired.
The decision about when to use each algorithm above has a great bearing
on performance and on how pretty the screen looks (how faithfully the
colors are rendered). If you rebuild the map and damage many canvases
each time a new color is used, performance will be poor; better to free
up maybe 1/3 of the color map each time you rebuild it, and have
'image' operators look ahead to find the total set of colors used if
they end up having to rebuild the color map, rather than do it several
times in a single imaging (or end up with inferior color choices).
Currently, all canvases of the same depth (8 bits only, in the current
NeWS implementation) seem to use the same color map. This probably
needs to be extended so that each unmapped canvas had its own color map
(requiring color maps to be merged when the canvas is mapped to a
screen, or in 'imagecanvas'). You can't assume a single frame buffer
(at least in the Mac market, we can't), though currently NeWS won't
run on multiple frame buffers; that will change sometime soon.
Comments?
--
John Gilmore {sun,pacbell,uunet,pyramid,amdahl}!hoptoad!gnu gnu@toad.com
A well-regulated militia, being necessary to the security of a free State,
the right of the people to keep and bear arms, shall not be infringed.