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

Even Rouault even.rouault at mines-paris.org
Thu Apr 14 13:46:32 EDT 2011


Le jeudi 14 avril 2011 17:02:36, Eli Adam a écrit :

I'm not aware of any recent change in the GTiff driver that could have "solved" 
the issue you've seen. This is a bit surprising.

Could you also try with the -stable builds (based on 1.8 branch) from 
http://vbkto.dyndns.org/sdk/ to compare ?

> 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
> 
> 
> 
> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev


More information about the gdal-dev mailing list