[GRASS5] lzw.c

[Eric G. Miller]

On Sun, Feb 24, 2002 at 06:06:49AM +0000, Glynn Clements wrote:
> 
> Looking through src/libes/gmath, I note that lzw.c is still there.
> Shouldn't this be removed?

I left it in for hysterical reasons.  How long's that patent good
for anyway?  It's not compiled in.  As long as it remains in source
form, the patent isn't violated in any reading of patent laws (and
certainly since similar code was widely published before the patent
was granted).  I thought it was code worth keeping around for 
reference...

> The only references to "lzw" outside of that file are in strings and
> comments:
> 
> src/libes/gis/G_dump.c:28:        fprintf(stderr,"max # bits used in lzw compression %d\n",G__.fileinfo[fd].compression_bits);
> src/libes/gis/closecell.c:347:      G_set_key_value ("lzw_compression_bits", msg, format_kv);
> src/libes/gis/put_row.c:645:/* i use a naive heuristic to set the max number of bits used for the lzw

That key_value thing is artifact code.  The lzw_bits should always = -1
for zlib rasters.  At a point, it was mutated to be a sentinel for data
in lzw vs. zlib.  It should probably come out all together.

> *except* that src/libes/g3d still appears to be using the G_lzw_*
> functions.

Hmm, if memory serves, at one time I thought I changed g3d to use
G_zlib_read()/write().  Nonetheless, g3d didn't use lzw by default
before.  It has some other significant bits/rle type
encoding/compression scheme (similar to CELL rasters, I guess).

-- 
Eric G. Miller <egm2 at jps.net>