Re: Another bug in 5.6.h

Stonie,

The image offset bug for the GINI NHEM WV image is caused by NESDIS creating
a bad image header stating the PDF offset is 0 bytes. The PDB offset is
supposed to be specified (but has always been 512 bytes). My guess is that your
program that produces the correct image has the 512 byte offset hard
coded instead of being read from the data....which may break in the future
if the PDB size is changed if compression or calibration information is
included. AWIPS hard codes a lot of this instead of reading from the data
which is why they had to release a new build when image areas were changed!
Note that you should get an IO message:
   Warning: PDB offset not 512 bytes

At any rate, I have included a check so that if the PDB offset is 0, then
it will be assumed to be 512 bytes.

The GEMPAK module is $GEMPAK/source/gemlib/im/imgi2gm.f

C*      Determine offset to start of data and data length
C*      Note: should read length to PDB from 45-46 (Chiz)
C
        nbytes = 2
        istart = igstrt + 45 - 1
        CALL MV_BTOI ( ignhdr, istart, nbytes, negflg, ioffpdb, ier )
        IF ( ioffpdb .ne. 512 ) THEN
           write(*,*) 'Warning: PDB offset not 512 bytes',ioffpdb
           IF ( ioffpdb .eq. 0 ) ioffpdb = 512
        END IF

This will be in the final 5.6.h tarfile...but you can fox that yourself if
you are compiling from source.

I have also fixed the ntl bug for little endian machines for the
shared color table, and found the Nsharp MODEL data widget bug
in using XtFree instead of XmStringFree for the
   "GEMPAK Model Data"
title that is ammended to report which model you have chosen
(seems to only show up on Linux). Anyhow, this was unrelated to
the number of files you might have in the directory.

Will look at the TOR problem in gpwarn today.

Thanks for the help in finding bugs (and where NESDIS doesn't follow
their own header standards).

Steve Chiswell

On Wed, 11 Sep 2002, Stonie R. Cooper wrote:

> Steve,
>
> I hope you have had a good return.  I haven't had time to track down the core
> file generators I mentioned to you earlier, but I have found another bug in
> gempak/nawips 5.6.h.
>
> The interpretation of the navigation block of the hemispheric GOES composites
> available on NOAAPort (4th channel) is skewed.  This had been working up
> through 5.6.e.1 (I skipped f) . . . and to illustrate, I have attached two
> images.
>
> The image "yahouw.gif" was generated with gpmap; the results are the same
> within NMAP/NSAT (so will be library based, I assume).  Note that the image
> was split and then mirrored.  The other attached image -
> "NHWV_20020911_1530.png" is how the data should be - i.e. it's just a
> straight gini->png conversion.
>
> I have checked the other images on NOAAPort, and this seems to be the only
> one that is incorrectly shown.
> --
> Stonie R. Cooper
> Planetary Data, Incorporated
> ph. (402) 782-6611
>