[Gdal-dev] r.out.gdal vs gdal_translate vs gdalwarp

Frank Warmerdam warmerdam at pobox.com
Wed Jun 6 10:34:17 EDT 2007


Maciej Sieczka wrote:
> "Frank Warmerdam-2" wrote:
> 
>> You could file a bug report on the issue, but it isn't likely to be very
>> high priority since there is a straight forward workaround.
> 
> I have just noticed that using compression might well boost the difference
> in gdalwarp and gdal_translate output.
> 
> 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.
> 
> It looks like it is *always* a good idea to process any gdalwarp GeoTIFF
> output with gdal_translate.

Maciek,

I believe this is a different issue.  "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.

I suspect this is the effect you are running into.

In this case gdal_translate is also helpful, though I can't really agree
with the rule in complete generality.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org




More information about the Gdal-dev mailing list