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

19990907: compression on GINI

>From: tomw <address@hidden>
>Organization: SSEC
>Keywords: 199909071750.LAA23950

Tom,

>Hope you had a nice, long weekend!!

It was definitely long!  I worked full days on Saturday and Sunday
on the ceiling over my front porch in Longmont (Mike Wright came
over on Saturday and helped; good thing).  Well, the ceiling is up
and it looks great!  Now, all that is needed is some washing (the
boards got dirty from our filthy hands), moulding in the corners
and priming and painting of areas near the ceiling.  I am going to
leave the ceiling boards their natural color since it looks so good
(they have all been waterproofed, so that should not be an issue).
So, the last _big_ job is like 99.9% finished!

>Say, in one of the gazillion messages floating around last week,
>you mentioned some discussions with NESDIS on ways to compress
>image data for distribution.

Right.  The GINI spec shows that there is a byte in the header that
indicates whether or not the image is compressed.  We had Linda Miller
contact folks at NESDIS about what the compression was going to
look like, but we found out that there are no plans at the moment
and the addition of compression has zero funding.  Since we are
grabbing the data off of COMET's NOAAPORT receiver, and since the
files can be HUGE, I figured that we could probably get our opinion
on what to do listened to by those that would make the decision
(unlike other, unnamed groups/people (wink, wink) :-)

>Could you give me a little background?  

Here are the results of some tests that Chiz ran on compression
strategies:

  From: Steve Chiswell <address@hidden>
  Date: Fri, 3 Sep 1999 10:55:18 -0600
  To: address@hidden, address@hidden,
          address@hidden, address@hidden
  Subject: Compression of GINI Satellite images
  
  I have some estimations from compression of a GINI satellite image.
  
  The GINI image format currently is 532 bytes of header information
  followed by a raster of 1 byte values, geometry of which is
  provided in bytes 17-18 and 19-20 of the data header.
  
  Starting with a sample visible image (2km Alaska region) as received on
  noaaport with size 3718533 bytes, the following compression values result:
  
                                     bytes
  Original no compression           3718533
  using gnu gzip entire image       2460988
  Using the zlib deflate
    on a per scanline basis         2645201
  Image block in pnm format          928944
  Image block in gif format          753166
  Image block in tiff format         749208
  Image block in png format          638003
  
  The png library also utilizes zlib compression.
  
  The advantage of using deflate is the ability to write software
  to efficiently grab a subsector of the image by adding a header
  of offsets for the scanlines. The advantage of using a well known
  image format for the body is maximizing the compressibility.
  
  Compression is important to consider for these images since
  the US visible images are 21 to 26 MB.
  
  Further thoughts?
  
  Chiz

>Thanks.

So, do you have any opinions?  If so, please pass them along.

Tom
--
+-----------------------------------------------------------------------------+
* Tom Yoksas                                             UCAR Unidata Program *
* (303) 497-8642 (last resort)                                  P.O. Box 3000 *
* address@hidden                                   Boulder, CO 80307 *
* Unidata WWW Service                             http://www.unidata.ucar.edu/*
+-----------------------------------------------------------------------------+