id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc 1688,gdalwarp creates GeoTIFFs bigger than gdal_translate,msieczka,warmerdam,"Analogous options settings in gdal_translate and gdalwarp result in GeoTIFF's of significantly different sizes. Example: $ gdal_translate vegcover3.tif vegcover3_gt.tif vegcover3_gt.tif size is 28628 bytes. Identical to input. OK. $ gdalwarp vegcover3.tif vegcover3_gw.tif vegcover3_gw.tif size is 36336 bytes. That's 27% bigger than the input! The bigger the output GeoTIFF, the smaller the difference in size. At circa 230 kB, the difference becomes almost neglectable. However, if one creates lots of small GeoTIFFs, this waists his disk and memory space considerably - eg. 500 10 kB GeoTIFFs from gdal_translate occupy 5 MB, while from gdalwarp it's 10 MB. The attached graph (gt_vs_gw.pdf; X axis should read ""gdal_translate output size [kB]"") shows how the size ratio changes with output raster size. Each raster was created and ""measured"" by script (gt_vs_gw.txt) and those measurements were used to create the graph. The very input raster is attached too (one.tif). Frank Warmerdam explained the reason: ""On careful review, the difference in the file in question is because gdal_translate uses the TIFFWriteScanline() interface to write the output file from within GTiffDataset::CreateCopy(), and this only writes as much of the final 'strip' of the file as is required to complete image area. But gdalwarp goes through the blockio interface which writes the complete final strip, even the portion that falls off the end of the file."" There was a discussion about this issue on GDAL dev list in May 2007 [1] continued in June [2]. [1]http://lists.maptools.org/pipermail/gdal-dev/2007-May/012997.html [2]http://lists.maptools.org/pipermail/gdal-dev/2007-June/013255.html ",defect,closed,normal,1.7.0,Algorithms,svn-trunk,major,fixed,gdalwarp,