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

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

David,

Wherever possible, I try to get useful code changes incorporated into
the core code release from NCEP. This helps prevent maintenance
problems by continually having to replace changes as new distributions arrive
(ie the imar2gm.f type of changes).

NCEP is very open to enhancements, so long as they don't interfere with
the requirements for the users which they must support. Also, since they
support operational use of the package for the National centers
(eg SPC, TPC, AWC, MPC, HPC, etc.), any changes they make have to be 
portable across the systems they support.

There are numerous location in the code included under 
$GEMPAK/source/driver/active/xw
that call DefaultDepth, and apparently in NPROGS too. I would assume that the 
goal of 
having a resource to define a prefered depth/visual and/or your code to find a 
visual/depth/window/display would be that once these are found, they should be 
a global 
variables stored in the header (or could be externs) that would be used instead 
of the 
X server calls like DefaultDepth.

Steve




>From: David Ovens <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200309232200.h8NM09k1018600

>Steve,
>
>I've modified xinita.c and it seems to be working for sfmap, gdplot,
>etc.  For the second 'xinita.c' did you mean gmpk.c?
>
>By the way, I am working on nsat right now, making the modification to
>gmpk.c.  My "make all" commands do not seem to work the way I would
>like (see below).  What is the preferred way to recompile a particular
>program?  Are there special make flags to use?  What doesn't nsat get
>re-made when I change gmpk.c?
>
>316 mm5rt@wrf18% make all
>gcc -DUNDERSCORE -DLinux -I/home/disk/wrf2/mm5rt/NAWIPS-5.6.J.uwpatched/gempak
> /include -I/usr/X11R6/include  -I/home/disk/wrf2/mm5rt/NAWIPS-5.6.J.uwpatched
> /include -I/usr/X11R6/include -I/usr/X11R6/include -c gmpk.c
>ar rv /home/disk/wrf2/mm5rt/NAWIPS-5.6.J.uwpatched/lib/linux/nsat.a prefw.o
>ar: prefw.o: No such file or directory
>make: *** [/home/disk/wrf2/mm5rt/NAWIPS-5.6.J.uwpatched/lib/linux/nsat.a] Erro
> r 1
>
>317 mm5rt@wrf18% ls -lt
>total 2592
>-rw-rw-r--    1 mm5rt    rmm5rt       6056 Sep 23 14:58 gmpk.o
>-rw-r--r--    1 mm5rt    rmm5rt      11518 Sep 23 14:57 gmpk.c
>-rwxrwxr-x    1 mm5rt    rmm5rt    2373298 Sep 23 14:08 nsat
>
>
>Also, will you make my modifications to xinita.c part of the standard
>GEMPAK distribution?
>
>David
>
>
>Unidata Support wrote:
>> 
>> 
>> 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 f
> or
>> >> >> 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 la
> rge
>> > 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 hom
> e
>> >> >> >-- 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 settin
> g
>> >> >> >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,C
> LRB
>> > 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 N
> ort
>> > hwe
>> >> > st
>> >> >> >Research Meteorologist
>> >> >> >Dept of Atmospheric Sciences, Box 351640
>> >> >> >University of Washington 
>> >> >> >Seattle, WA  98195
>> >> >> >
>> >> >> 
>> >> >> **********************************************************************
> ***
>> > ***
>> >> >> Unidata User Support                                    UCAR Unidata P
> rog
>> > ram
>> >> >> (303)497-8643                                                  P.O. Bo
> x 3
>> > 000
>> >> >> address@hidden                                   Boulder, CO
>  80
>> > 307
>> >> >> ----------------------------------------------------------------------
> ---
>> > ---
>> >> >> Unidata WWW Service              http://my.unidata.ucar.edu/content/su
> ppo
>> > rt 
>> >> >> **********************************************************************
> ***
>> > ***
>> >> >> 
>> >> >
>> >> >
>> >> >-- 
>> >> >
>> >> >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
>