Opened 17 years ago

Closed 16 years ago

#1689 closed defect (duplicate)

gdalwarp -co "COMPRESS=DEFLATE" output 45% too big

Reported by: msieczka Owned by: warmerdam
Priority: normal Milestone:
Component: GDAL_Raster Version: svn-trunk
Severity: major Keywords:
Cc:

Description

Using compression with gdalwarp results in a GeoTIFF much bigger than with gdal_translate. Example:

I have a GeoTIFF which is 47,605,938 bytes uncompressed. Deflated with gdalwarp it's 20,513,882 bytes, while deflated with gdal_translate it's 13,734,032 bytes. 7 MBs, 45% difference. One has to process his gdalwarp GeoTIFF output with gdal_translate to get rid of spurious bytes.

Frank Warmerdam explains on GDAL dev list:

"Random update" of compressed images was not traditionally supported by libtiff, but I have hacked in some degree of support for this over the last half dozen years. This is sufficient to allow gdalwarp to write compressed geotiff files.

But, when a given tile or scanline gets rewritten (since gdalwarp operates on regions not related to tile boundaries) it is moved to the end of the file if it will be larger on disk than the previous version of that tile was. The old space is abandoned and not reused.

Change History (2)

comment:1 by msieczka, 16 years ago

Severity: normalmajor
Version: 1.4.1svn-trunk

Many times I have experienced much worse ratios that the 45% mentioned above.

Max I remember I had was 13:1.

For example, with the 290 MB GeoTIFF available at [1], 'gdalwarp -co "COMPRESS=LZW"' vs 'gdal_translate -co "COMPRESS=LZW"' ratio is 5:1. For the same data the 'gdalwarp -co "COMPRESS=LZW"' vs 'gdalwarp -co "COMPRESS=NONE"' is about 3:1.

Compressed raster must not be bigger than uncompressed. gdalwarp and gdal_translate should create rasters of circa the same size.

[1]http://www.biol.uni.wroc.pl/sieczka/udostepnione/M-33-21-A-b-4.tif

comment:2 by maphew, 16 years ago

Resolution: duplicate
Status: newclosed

same as #1688

Note: See TracTickets for help on using tickets.