[gdal-dev] gdaladdo creates very large files in 1.8 but not trunk

[Eli Adam]

This is an informational report only, there are not problems in trunk.  

Using 1.8.0 from OSGeo4W on XP, I made a mosaic of about 1200 uncompressed tifs totally 80G.  

gdalbuildvrt mosaic.vrt *.tif

Then gdal_translated that to a compressed tif of about 8G

gdal_translate mosaic.vrt mosaic_ycbcr_big.tif -co COMPRESS=JPEG -co PHOTOMETRIC=YCBCR -co TILED=YES -co BIGTIFF=YES --config GDAL_CACHEMAX 800

Last step was to add some overviews:

gdaladdo --config COMPRESS_OVERVIEW JPEG --config PHOTOMETRIC_OVERVIEW YCBCR --config INTERLEAVE_OVERVIEW PIXEL --config BIGTIFF_OVERVIEW YES --config GDAL_CACHEMAX 800 -r average -ro mosaic_ycbcr_big.tif 2 4 8 16 32 64 128

It works (at least in OpenEV it displays quickly like it is using overviews), except the file sizes for the overviews seem odd and too large.    

The tiles are about 80G, the result of gdal_translate is 8G, the result of gdaladdo, mosaic_ycbcr_big.tif.ovr,  is 375G!  That was using 1.8.0.

I tested on trunk on ubuntu and XP from here, http://vbkto.dyndns.org/sdk/ which produce reasonable results.  The ovr is about 3G.  

A dif of gdalinfo on the .tif and .ovr are the same.

(I hope that is not the result of a typo when I initially typed the command.  I unfortunately don't have the shell around any more but took the above listed commands from some notes I took.)

I have tried making the overviews internal and external with similar results.  I also tried making the overviews on the uncompressed files (the vrt) with the same results.  Then I made the overviews 1 level at a time and those results seemed reasonable.  

I didn't find any tickets about this in trac, but don't experience this in trunk so apparently it is fixed.  Just reporting in case it is useful.  

Do you want any other information?  

Thanks, Eli