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

20010312: LONG overdue email regarding zlib compressed NIDS imagery



>From: Tom Yoksas <address@hidden>
>Organization: Unidata Program Center/UCAR
>Keywords: 200012082041.eB8KfKE6966046 NOAAPORT NEXRAD Level III zib compress

Dan,

Well this email has certainly taken way longer to get sent than I
intended!  I have finally taken some time to weed through my
exceedingly long email backlog when I happened upon an email from Chiz
in reference to the zlib compression of NOAAPORT Level III products.

Back in January at the AMS meeting in ABQ, I mentioned to you that the
test that you were (are?) using to see if a NIDS image was zlib
compressed (I was using the same test for McIDAS code) could become
invalid if the NWS changes their compression strategy.

The following note from Chiz to myself and Russ Rew is in reference to
the process of determining if a block in the images is zlib compressed
or not:

------- Forwarded Message

From: Steve Chiswell <address@hidden>
Date: Fri, 8 Dec 2000 13:41:20 -0700
To: Tom Yoksas <address@hidden>, Russ Rew <address@hidden>
Subject: zlib magic number?

Tom and Russ,

Previously we discussed if one could globally guarantee that the first 2 bytes
of a zlib compressed product were 0x78 and 0x9C. This is true for the
products we are currently receiving. Also, I see that Dan is requiring that
fact. However, this is not the check that the inflate.c code uses. 

The actual conditions in the inflate.c code are:

The first inflate check assumes:
   byte[0] & 0xf == Z_DEFLATED        <<-- this can only be "8" in the current
                                           1.1.3 zlib version (eg, this is the
                                           only compression available).
                                           0x78 & 0xf == 8

The second inflate test asserts:
   (byte[0] >> 4) + 8 <= DEF_WBITS     <<-- DEF_WBITS = MAX_WBITS is 15 unless
                                            otherwise redefined.
                                            0x78 >> 4 + 8 = 15
 
Lastly, the first 2 byes should be evenly divisible by 31:

   (byte[0] << 8) + byte[1] % 31 == 0  <<-- 30876 % 31 = 0


So, assuming 0x78 and 0x9C are the first 2 bytes is a trivial test, but not
very robust if the zlib library ever changes, or the NCEP people decide
to change the number of compression bits for some optimization reason.

Chiz

------- End of Forwarded Message

Anyway, sorry this took so long to get to you!  I hope that it helps...

Tom

>From: "Dan Vietor" <address@hidden>
>To: "'Tom Yoksas'" <address@hidden>
>Subject: RE: 20010312: LONG overdue email regarding zlib compressed NIDS 
>imagery
>Date: Mon, 12 Mar 2001 15:25:44 -0500

Thanks!  I knew you'd come through.  I owe you a beer!

After I got back, I did some quick research and didn't get very far.
This will help.

________________________________________________________
Daniel Vietor               Mail: address@hidden
Unisys Corp                 Title: Engineer/Meteorologist
221 Gale Lane               Phone: 610-925-5206
Kennett Square PA 19348     Fax: 610-925-5215