This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>From: Peter Schmid <address@hidden> >Organization: UCAR/Unidata >Keywords: 200008241504.e7OF4uN13957 >Hi, > >I have a question on some strange results specifing rgb values >with the COLORS= keywork in a gempak script while NTL is running. >Here is the sequence of events: > >1. Run ntl in the background with no optional parameters. >2. Run a gempak script with a COLORS=3 keyword. >3. Then that same script with colors = 3=128:255:128 > >The two gif images (DEVICE = GF BTW) produce the correct >difference. The problem is if you then run the 1st script >with COLORS=3, the output is the same as the colors = 3=128:255:128 >script. > >It seems as thought that specifing the rgb values changes the >default colors as long as NTL is running. This problem does >not occur if NTL is _not_ running. > >Any thoughts or ideas? > >Thanks, > >Pete. >Peter Schmid >Sr. Programmer/Analyst SUNY at Albany >Department of Earth and Atmospheric Sciences >Phone:(518)-442-4571 >E-Mail:address@hidden > > Pete, When NTL runs, it sets up a SHAREABLE color table that all the gempak programs will use. When a program runs, it finds out if the SHAREABLE color table exists, and if so- uses that instead of the $GEMTBL/colors/ entry for the device. So, if you change the color, it will stay in the SHAREABLE color table. If you run without NTL, then you get the private colormap every time. I use the Xvfb server to generate my gif images to a display:1.0, so that I don't run into conflicts with the shared colormap that the viewable display has. Steve CHiswell