lively@sunybcs.uucp (Richard S. Lively) (12/03/88)
Suppose that you are using a multiple window environment on a
color workstation. You are using a single window which requires the
use of 150 entries in the color lookup table and now you want to open
another window which requires another 150 entries in the lookup table
(potentially there will be no similar colors in the separate windows).
However, there are not enough available slots in the lookup table to support
that many entries. How can you maintain color integrity in both windows?
When I asked how different windowing environments handle this, I received
the following responses:
SunView - any window except active window is black
X - does not allow creation of the second window
Mac II - separate lookup table for each window (but
not exactly perfect)
Are these answers correct? If so, what design decisions prompted these
choices? Is there any reason that each window can't have a separate
lookup table which can become active or inactive dynamically in the
middle of a scan line?bam@sbc2.SGI.COM (Brian A. McClendon) (12/03/88)
article <3048@cs.Buffalo.EDU>, lively@sunybcs.uucp (Richard S. Lively) writes: > (deleted) > When I asked how different windowing environments handle this, I received > the following responses: > > SunView - any window except active window is black > X - does not allow creation of the second window > Mac II - separate lookup table for each window (but > not exactly perfect) > SGI (GL) - When a LUT is loaded by a process, it REALLY gets loaded. Any info about the previous contents is lost. In the 12 bitplane case, 16 different 256 entry tables can coexist, but it is up to the application to avoid others' tables. Intergraph - Each process (not each window) has a 'virtual' (Environ V) LUT that is only loaded when the process has the input focus. New processes adopt the current LUT as an initial state to minimize ugliness. > Are these answers correct? If so, what design decisions prompted these > choices? Is there any reason that each window can't have a separate > lookup table which can become active or inactive dynamically in the > middle of a scan line? Loading a LUT in mid scanline is usually unrealistic/impossible. Many of the workstation-rated(KxK +) output tables can't be loaded anytime except vertical blank and when the tables hit upwards of 4096 entries, it is difficult to load completely in only one VB. The Atari ST has some programs (Spectrum 512 is the main example) that produce up to 512 colors on the screen at once using only 4 bits/pixel. They load up to about 16 entries per horizontal scanline but that trick is a hack, not a Atari-approved feature. -- - brian Brian McClendon uucp: ...!uunet!sgi!bam work: 415-335-1110
peter@ficc.uu.net (Peter da Silva) (12/05/88)
article <3048@cs.Buffalo.EDU>, lively@sunybcs.uucp (Richard S. Lively) writes: > When I asked how different windowing environments handle this, I received > the following responses: > > SunView - any window except active window is black > X - does not allow creation of the second window > Mac II - separate lookup table for each window (but > not exactly perfect) Amiga - Multiple 'screens' are possible, each with their own bitplanes, display modes, and LUT. Screens can be stacked vertically but not horizontally, and contain their own windows. The user can slide screens up and down, but not sideways. This is implemented by having a coprocessor that can be programmed to switch the display on a scanline basis. I suspect that switching within a scanline would be prohibitively expensive, but I'm not familiar with the hottest display chips... I know some of them support hardware windows that switch bitplanes at a pixel's notice. So, if you want your own LUT you're supposed to open a new screen first. -- Peter da Silva `-_-' Ferranti International Controls Corporation "Have you hugged U your wolf today?" uunet.uu.net!ficc!peter Disclaimer: I accept full responsibility for my typos. peter@ficc.uu.net
viraf@gwusun.gwu.edu (Viraf Bankwalla) (04/11/89)
Hi,
I have written a program that converts sun raster files to PICT
format, but the colors are off. The sun uses 8 bit values in its
color lookup table, while the Mac uses 16 bit values. I simply shift
the RGB components left 8 times - but that introduces green in some
parts of the image, that should be orange.
How should one go around converting 8 bit color values to 16 bits,
and vice versa.
Thanks in advance.
viraf bankwalla
viraf@gwusun.gwu.edu
uunet!gwusun!virafjbm@eos.UUCP (Jeffrey Mulligan) (04/12/89)
From article <1322@gwusun.gwu.edu>, by viraf@gwusun.gwu.edu (Viraf Bankwalla): > I have written a program that converts sun raster files to PICT > format, but the colors are off. The sun uses 8 bit values in its > color lookup table, while the Mac uses 16 bit values. I simply shift > the RGB components left 8 times - but that introduces green in some > parts of the image, that should be orange. I suspect the problem is caused by different nonlinearities (gamma functions) in your two monitors. If the monitors were both perfectly linear, then what you did should have worked. The best way to go would be to calibrate each monitor (i.e., measure the luminance produced at each gun setting). Then you can convert from the hardware LUT settings to luminance, and then back again to the other hardware. -- Jeff Mulligan (jbm@aurora.arc.nasa.gov) NASA/Ames Research Ctr., Mail Stop 239-3, Moffet Field CA, 94035 (415) 694-6290