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.
David, Your code can be applied to: $GEMPAK/source/driver/active/xinita.c The other routines that call DefaultDepth should instead use a values defined in xinita.c. Steve Chiswell >From: David Ovens <address@hidden> >Organization: UCAR/Unidata >Keywords: 200309222127.h8MLRKk1014284 >Steve, > >As for this, > > In the case of GEMPAK, it will use the default visual of the > > system, there is no way to configure it to use a different visual > > ID. >it actually seems like it ought to be pretty easy to modify the code >to take a PseudoColor (8-bit) visual if the system has one and >otherwise to use the default. Here is a quick C/X11 program I wrote >which does just that: > >+++++++++++++++++++++++++ myxinfo.c ++++++++++++++++++++++++++++++++++++ >/* Linux: gcc -o myxinfo.`uname -s` -L/usr/X11R6/lib -lX11 myxinfo.c > */ >/* SunOS: cc -o myxinfo.`uname -s` -lX11 myxinfo.c */ >#include <string.h> >#include <stdio.h> >#include <stdlib.h> >#include <X11/Xlib.h> >#include <X11/Xutil.h> > >main(int argc, char *argv[]) { > void usage(void); > Display *dpy; > Window win; > > int i; > int debug = 0; > int scr; > > XVisualInfo viproto; /* fill in for getting info */ > XVisualInfo *vip; /* retured info */ > int nvi; /* number of elements returned */ > int psvisual = -1; > char *class = NULL; /* for printing */ > > dpy = XOpenDisplay(0); > if (!dpy) > { > fprintf(stdout, "Cannot open the display.\n"); > return(0); > } > scr = DefaultScreen(dpy); > > nvi = 0; > viproto.screen = scr; > vip = XGetVisualInfo (dpy, VisualScreenMask, &viproto, &nvi); > printf (" default visual id: 0x%lx\n", > XVisualIDFromVisual (DefaultVisual (dpy, scr))); > printf (" checking all %d visuals for a PseudoColor \n", nvi); > for (i = 0; i < nvi; i++) { > if ((vip+i)->class == PseudoColor) { > printf (" got PseudoColor visual for \n"); > printf (" visual id: 0x%lx\n", (vip+i)->visualid); > printf (" depth: %d plane%s\n", (vip+i)->depth, > (vip+i)->depth == 1 ? "" : "s"); > psvisual = i; > break; > } > } > if (psvisual == -1) { > printf (" ** did not find PseudoColor visual, using default \n"); > printf (" visual id: 0x%lx\n", vip->visualid); > printf (" depth: %d plane%s\n", vip->depth, > vip->depth == 1 ? "" : "s"); > } > XCloseDisplay(dpy); > return(0); > >} >+++++++++++++++++++++++++ myxinfo.c ++++++++++++++++++++++++++++++++++++ > >Any chance this type of approach could be added to NPROGS and GEMPAK >in general? > >David > >Unidata Support wrote: >> David, >> >> I don't have any experience with PC graphics cards in this manner. >> The gembud list may be a place to see if anyone else has such a >> configuration. > >> I have run xnest for creating an 8 bit desktop in a 24 bit display. >> The XFree86 server at last dcheck does not allow multiple visuals, >> so even though you can have both 8 bit at 24 bit color, they both >> are true color. Note that this is a limitation of XFree86, and not >> xnest (which works fine on more advanced X servers that support >> multiple visuals). > >> In the case of GEMPAK, it will use the default visual of the >> system, there is no way to configure it to use a different visual >> ID. >> >> Steve Chiswell >> >> >> >From: David Ovens <address@hidden> >> >Organization: UCAR/Unidata >> >Keywords: 200309191715.h8JHF9k1022085 >> >> >Steve, >> > >> >I'm now thinking about purchasing an nvidia Quadro 4 or FX card that >> >would support an 8-bit "Overlay" in 24-bit displays. If we could have >> >the default visual as 24-bit and an optional 8-bit overlay, how could >> >I use the 8-bit one for GEMPAK? In xanim and xv, for example, I can >> >specify any of the visuals I have present on my Sun with a >> >command-line option. Is there a command-line option or Xresouce that >> >could do this for GEMPAK? >> > >> >By the way, I did discover that the lowest memory usage way to look at >> >the EAST-CONUS/1km/VIS imagery in NMAP/GARP is to do something like >> >"Roam" = "6 x Screen Size" and then to do a zoom. This keeps >> >the roam area down to a limited portion of the original 5120x5120 >> >image. >> > >> >David >> > >> >Unidata Support wrote: >> >> >> >> >> >> David, >> >> >> >> The problem with 8 bit color under Xfree86 4.2 is that >> >> the window manager allocates most of the colors, and you >> >> are left with only 12 free color cells. There were reportedly >> >> some patches to the XFree86 to remedy that problem >> >> (I'm assuming you have the same problem under Debian as >> >> RH). Likely your old RH7.0 at home is running an older version >> >> of XFree86 (which is a good thing in this case!). >> >> >> >> I haven't looked at the current state of XFreee86 patches since >> >> going to 24 bit under Linux. Users were doing CVS checkout of source for >> >> patches and rebuilding....hopefully its easier than that now. >> >> >> >> Note that you can also sample the 1km gini in either >> >> space or resolution using the SECTOR program which is >> >> useful if you want 1 faster loading (less memory) image >> >> at top resolution for your area, or don't need 1km resolution for a large > r a >> > rea. >> >> >> >> Steve Chiswell. >> >> >> >> >> >> >> >> >From: David Ovens <address@hidden> >> >> >Organization: UCAR/Unidata >> >> >Keywords: 200309182106.h8IL6jk1020275 >> >> >> >> >Hello, >> >> > >> >> >I have an older version of GEMPAK on my Linux box (RedHat 7.0) at home >> >> >-- 5.6.A? 5.6.D? -- and the only way I can get it to work is to run >> >> >with PseudoColor (8-bit) not DirectColor (24-bit). I've lived and >> >> >worked with that just fine. >> >> > >> >> >Now, I am trying to look at 10 EAST-CONUS/1km/VIS/ GINI images setting >> >> >the "Roam" to "Size of Image". Since my giniinfo program (available >> >> >if you want it as a GEMPAK contrib program) tells me the images are >> >> >5120x5120, you can imagine that this is going to require some memory. >> >> >Close to 1 GB in 24-bit mode, but considerably less in 8-bit. >> >> >Unfortunately, at work here, I cannot seem to get any GEMPAK programs >> >> >to run under 8-bit (the opposite of home). >> >> > >> >> >Is this due to Debian Linux at work or some change in GEMPAK? >> >> > >> >> >Any idea how I can run in 8-bit with 5.6.H or later GEMPAK on Linux? >> >> > >> >> >The types off errors I'm getting are these: >> >> > >> >> >sfmap errors: >> >> >Creating process: xw for queue 163843 >> >> > [GEMPLT -46] NCLRAL - Can not allocate read/write colors. >> >> > Parameters requested: AREA,GAREA,SATFIL,RADFIL,SFPARM,DATTIM,SFFILE,COL > ORS >> > , >> >> > MAP,LATLON,TITLE,CLEAR,PANEL,DEVICE,PROJ,FILTER,TEXT,LUTFIL,STNPLT,CLRB > AR, >> >> > IMBAR. >> >> > GEMPAK-SFMAP>e >> >> > >> >> >garp errors: >> >> >G A R P - v2.1 starting... >> >> >Warning: Cannot allocate colormap entry for "deepskyblue4" >> >> >InitGempakColorMap: Can't allocate Graphic colors. >> >> >GarpInitialize: GempakInit failed >> >> >Main: Initialization failed. Exiting >> >> > >> >> >ntl errors: >> >> >Warning: Cannot allocate colormap entry for "grey75" >> >> >Resource File: /home/disk/ldm/NAWIPS-5.6.H/resource/Ntop >> >> >graphic, satellite, radar, fax -- 33 95 20 2 >> >> > Request total # of colors = 150 >> >> >X Error of failed request: BadValue (integer parameter out of range for > op >> > era >> >> > tion) >> >> > Major opcode of failed request: 86 (X_AllocColorCells) >> >> > Value in failed request: 0x0 >> >> > Serial number of failed request: 413 >> >> > Current serial number in output stream: 413 >> >> > >> >> >freeColors shows 12: >> >> > CURRENTLY YOUR SYSTEM HAS: >> >> > ======================================== >> >> > 256 total color cells. >> >> > 12 free color cells. >> >> > 244 shared read-only color cells. >> >> > 0 private writeable color cells. >> >> > ======================================== >> >> > >> >> >and the rest is xdpyinfo output: >> >> >name of display: :0.0 >> >> >version number: 11.0 >> >> >vendor string: The XFree86 Project, Inc >> >> >vendor release number: 40201000 >> >> >XFree86 version: 4.2.1 >> >> >maximum request size: 4194300 bytes >> >> >motion buffer size: 256 >> >> >bitmap unit, bit order, padding: 32, LSBFirst, 32 >> >> >image byte order: LSBFirst >> >> >number of supported pixmap formats: 7 >> >> >supported pixmap formats: >> >> > depth 1, bits_per_pixel 1, scanline_pad 32 >> >> > depth 4, bits_per_pixel 8, scanline_pad 32 >> >> > depth 8, bits_per_pixel 8, scanline_pad 32 >> >> > depth 15, bits_per_pixel 16, scanline_pad 32 >> >> > depth 16, bits_per_pixel 16, scanline_pad 32 >> >> > depth 24, bits_per_pixel 32, scanline_pad 32 >> >> > depth 32, bits_per_pixel 32, scanline_pad 32 >> >> >keycode range: minimum 8, maximum 255 >> >> >focus: PointerRoot >> >> >number of extensions: 30 >> >> > BIG-REQUESTS >> >> > DEC-XTRAP >> >> > DOUBLE-BUFFER >> >> > DPMS >> >> > Extended-Visual-Information >> >> > FontCache >> >> > GLX >> >> > LBX >> >> > MIT-SCREEN-SAVER >> >> > MIT-SHM >> >> > MIT-SUNDRY-NONSTANDARD >> >> > NV-CONTROL >> >> > NV-GLX >> >> > NVIDIA-GLX >> >> > RECORD >> >> > RENDER >> >> > SECURITY >> >> > SHAPE >> >> > SYNC >> >> > TOG-CUP >> >> > XC-APPGROUP >> >> > XC-MISC >> >> > XFree86-Bigfont >> >> > XFree86-DGA >> >> > XFree86-Misc >> >> > XFree86-VidModeExtension >> >> > XInputExtension >> >> > XKEYBOARD >> >> > XTEST >> >> > XVideo >> >> >default screen number: 0 >> >> >number of screens: 1 >> >> > >> >> >screen #0: >> >> > dimensions: 1280x1024 pixels (342x271 millimeters) >> >> > resolution: 95x96 dots per inch >> >> > depths (7): 8, 1, 4, 15, 16, 24, 32 >> >> > root window id: 0x41 >> >> > depth of root window: 8 planes >> >> > number of colormaps: minimum 1, maximum 1 >> >> > default colormap: 0x20 >> >> > default number of colormap cells: 256 >> >> > preallocated pixels: black 0, white 1 >> >> > options: backing-store YES, save-unders YES >> >> > largest cursor: 64x64 >> >> > current input event mask: 0x0 >> >> > number of visuals: 6 >> >> > default visual id: 0x21 >> >> > visual: >> >> > visual id: 0x21 >> >> > class: PseudoColor >> >> > depth: 8 planes >> >> > available colormap entries: 256 >> >> > red, green, blue masks: 0x0, 0x0, 0x0 >> >> > significant bits in color specification: 8 bits >> >> > visual: >> >> > visual id: 0x22 >> >> > class: GrayScale >> >> > depth: 8 planes >> >> > available colormap entries: 256 >> >> > red, green, blue masks: 0x0, 0x0, 0x0 >> >> > significant bits in color specification: 8 bits >> >> > visual: >> >> > visual id: 0x23 >> >> > class: StaticColor >> >> > depth: 8 planes >> >> > available colormap entries: 256 >> >> > red, green, blue masks: 0x7, 0x38, 0xc0 >> >> > significant bits in color specification: 8 bits >> >> > visual: >> >> > visual id: 0x24 >> >> > class: TrueColor >> >> > depth: 8 planes >> >> > available colormap entries: 8 per subfield >> >> > red, green, blue masks: 0x7, 0x38, 0xc0 >> >> > significant bits in color specification: 8 bits >> >> > visual: >> >> > visual id: 0x25 >> >> > class: DirectColor >> >> > depth: 8 planes >> >> > available colormap entries: 8 per subfield >> >> > red, green, blue masks: 0x7, 0x38, 0xc0 >> >> > significant bits in color specification: 8 bits >> >> > visual: >> >> > visual id: 0x26 >> >> > class: StaticGray >> >> > depth: 8 planes >> >> > available colormap entries: 256 >> >> > red, green, blue masks: 0x0, 0x0, 0x0 >> >> > significant bits in color specification: 8 bits >> >> > >> >> > >> >> > >> >> >Thanks, >> >> > >> >> >David >> >> >-- >> >> > >> >> >David Ovens e-mail: address@hidden >> >> >(206) 685-8108 plan: Real-time MM5 forecasting for Pacific Nort > hwe >> > st >> >> >Research Meteorologist >> >> >Dept of Atmospheric Sciences, Box 351640 >> >> >University of Washington >> >> >Seattle, WA 98195 >> >> > >> >> >> >> ************************************************************************* > *** >> >> Unidata User Support UCAR Unidata Prog > ram >> >> (303)497-8643 P.O. Box 3 > 000 >> >> address@hidden Boulder, CO 80 > 307 >> >> ------------------------------------------------------------------------- > --- >> >> Unidata WWW Service http://my.unidata.ucar.edu/content/suppo > rt >> >> ************************************************************************* > *** >> >> >> > >> > >> >-- >> > >> >David Ovens e-mail: address@hidden >> >(206) 685-8108 plan: Real-time MM5 forecasting for Pacific Northwe > st >> >Research Meteorologist >> >Dept of Atmospheric Sciences, Box 351640 >> >University of Washington >> >Seattle, WA 98195 >> > >> >> **************************************************************************** >> Unidata User Support UCAR Unidata Program >> (303)497-8643 P.O. Box 3000 >> address@hidden Boulder, CO 80307 >> ---------------------------------------------------------------------------- >> Unidata WWW Service http://my.unidata.ucar.edu/content/support >> **************************************************************************** >> > > >-- > >David Ovens e-mail: address@hidden >(206) 685-8108 plan: Real-time MM5 forecasting for Pacific Northwest >Research Meteorologist >Dept of Atmospheric Sciences, Box 351640 >University of Washington >Seattle, WA 98195 >