[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20030922: 20030919: 20030918: GEMPAK and pseudo-color on Linux
- Subject: 20030922: 20030919: 20030918: GEMPAK and pseudo-color on Linux
- Date: Mon, 22 Sep 2003 15:45:41 -0600
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
>
- Prev by Date: 20030918: Gempak - Solaris - New binary for 5.6k?
- Next by Date: 20030923: nex2img stuff
- Previous by thread: 20030918: Gempak - Solaris - New binary for 5.6k?
- Next by thread: 20030923: nex2img stuff
- Index(es):