On 11-06-15 01:43 PM, Matt Wilkie wrote:
Hi Folks,
I've run into a strange thing, "gdal_translate -co compress=lzw" is creating
files that are larger than the source uncompressed image.
Input:
04/04/2006 08:39 AM 959,236,993 A1.tif
Results of "gdal_translate -co compress=[lzw,packbits,none]"
15/06/2011 10:35 AM 1,003,987,364 _lzw.tif
15/06/2011 10:31 AM 958,908,507 _none.tif
15/06/2011 10:30 AM 965,940,411 _packbits.tif
gdalinfo report is attached.
source file at http://files.environmentyukon.ca/matt/gdal-trans-lzw/ (in about
20 minutes).
GDAL 1.8.0, released 2011/01/12
Matt,
LZW compression packs a little dictionary at the front of each strip/tile
with the table of patterns. The size of an LZW compressed image can be
noticably larger than an uncompressed image if the chunk size (strip/tile)
is small so that this overhead becomes significant, and of course if the
imagery is essentially uncompressable with LZW.
Using larger strip/tile sizes can improve efficiency with LZW.
Also, using -co PREDICTOR=2 can help with imagery that is smoothly
varying as it compresses the differences from pixel to pixel instead of
the absolute values, and these will tend to be small and have more
patterns.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
