[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 20030919: 20030918: GEMPAK and pseudo-color on Linux
- Subject: Re: 20030919: 20030918: GEMPAK and pseudo-color on Linux
- Date: Mon, 22 Sep 2003 14:27:14 -0700 (PDT)
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 larger
> >> 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,COLORS
> > ,
> >> > MAP,LATLON,TITLE,CLEAR,PANEL,DEVICE,PROJ,FILTER,TEXT,LUTFIL,STNPLT,CLRBAR,
> >> > 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
> >> >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
> >
>
> **************************************************************************** <
> 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