[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20030922: 20030919: 20030918: GEMPAK and pseudo-color on Linux

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
>