[gdal-dev] LZW Compression on geotiffs

[Armin Burger]

I would also always recommend to use -co PREDICTOR=2 when compressing 
with LZW (or DEFLATE). So far I made quite good experiences with LZW and 
PREDICTOR=2, with typical compression rates close to gzip compression 
(meaning when putting the tif file into a tgz archive file).

The only time that I discovered where LZW does not work well was when 
using gdalwarp and directly writing the output as (untiled) LZW TIFF. 
This could create LZW files up to 2-3 times bigger than the uncompressed 
input TIFF. When using gdalwarp and one wants to save disk space one 
should either create tiled LZW TIFF's, or warp to uncompressed TIFF and 
then use gdal_translate with LZW to create the final LZW image, 
PREDICTOR=2 is recommended for both methods.

armin


On 10/02/2014 01:13 AM, Even Rouault wrote:
> Le jeudi 02 octobre 2014 01:06:57, David Strip a écrit :
>> On 10/1/2014 12:02 PM, Jukka Rahkonen wrote:
>>
>> For comparison:
>> Tiff as zipped    347 MB
>> Tiff into png     263 MB
>> If I have understood right both zip and png are using deflate algorithm so
>> there might be some place for improving deflate compression in GDAL.
>>
>>   I was curious how png could achieve such  better compression if it is
>> using the same deflate algorithm. I wouldn't think different
>> implementations would account for so much improvement. It turns out the
>> png compression uses a "filtering" step ahead of compression. This is
>> explained here. The filter is similar to a differential pulse code
>> modulation, in which the pixel is represented as the difference from the
>> pixels to the left, left upper diagonal, and above. This typically reduces
>> the magnitude of the value to something close to zero, making the encoding
>> more efficient.
>
> True, a way to improve things might be to specify -co PREDICTOR=2. Should
> apply to both LZW and DEFLATE.
> This is one of the filter that might be used by PNG, except that PNG has
> different filters, so it will eventually beat TIFF deflate.
>
>>
>>   David
>