[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20030919: 20030918: GEMPAK and pseudo-color on Linux
- Subject: 20030919: 20030918: GEMPAK and pseudo-color on Linux
- Date: Mon, 22 Sep 2003 11:09:11 -0600
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 t he 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
>