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

20020726: 20020725: GEMPAK 16/24 bit color modifications

Art,

I did some reconfiguration. The primary problem was that
the xgbank.c routine doesn't know if it is getting the
4 byte values you were creating in colr.c in the 16/14
bit section, or normally 1 byte values from the 8 bit mode.
I re-modified colr.c routine as well as xgbank.c
so that your 4 byte values can be retrived from the shared color table
set up by ntl.

Ncolor will now correctly get the graphic color table from
the Atom created from ntl. However, the concept of the program
is geared to changing the color table for 8 bit, and so 
editing color values is not realy the same as in TrueColor mode,
so the logic of the program will need a little more work I believe.

Anyhow, I wanted to let you know that the work you did was appreciated
and I will be trying to implement the full range of programs
(did you work on nmap2? your tarfile didn't have anything there).

I have to put this down for now since the GEMPAK workshop is next week.

Steve Chiswell
Unidata User Support

>From: "Arthur A. Person" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200207261551.g6QFpS920852

>Steve,
>
>On Thu, 25 Jul 2002, Steve Chiswell wrote:
>
>> I've made a little progress in getting your modifications to work
>> on my machines here.
>>
>> Some problems I had were:
>>
>> 1) the MAXCOLORDATA definition in xwcmn.h is set to 512.
>>
>>    In ntl/colr.c colr_init(), the number of bytes being generated
>>    in the xcsdat call for my number of colors (33 Graph, 95 Sat,
>>    20 rad, 2 fax) was 620....so memory was getting clobbered. I changed
>>    MAXCOLORDATA to 2048 (4x previous) in my distribution.
>>
>> 2) also in ntl/colr.c, you had:
>>
>>    unsigned int   sendcolr[MAXCOLORDATA],*dptr;
>>
>>    this created problems for me when extracting the information
>>    back out of the shared color map since the expected size in
>>    xcsdat.c and xgbank.c (through call to xgsdat.c) of
>>    the data is unsigned char. The result was getting
>>    garbage off by 4xbyte in the shared color map in xgbank.
>>
>>    I changed this to
>>
>>     unsigned char   sendcolr[MAXCOLORDATA],*dptr;
>>
>>
>> At this point I am able to launch ntl and nsat on a 24 bit display
>> (without the above changes, I could launch nsat only if ntl wasn't running).
>
>Bugs?  What bugs...?  :)
>
>Actually, I started with the garp/gempak stuff and spent the most time on
>that since that's what we use the most, although there's extensive use of
>the nmap application also.  I worked on the "N" programs last and I tested
>them by running them individually rather than through ntl.  I think you'll
>find that ncolor isn't working since it seems to involve interprocess
>communication of color information via X and I couldn't decide how to fix
>it easily.  If that's an issue and no one else has time work on it, let me
>know and I'll try and put some more effort into it and the "N" programs in
>general.
>
>                                   Art.
>
>Arthur A. Person
>Research Assistant, System Administrator
>Penn State Department of Meteorology
>email:  address@hidden, phone:  814-863-1563
>