Dear list, When i try to write a floating point Geotiff from Python (both 32 or 64 bit), the resulting file size is significantly larger compared to the output of gdal_translate. I wrote a small test script which tests this it for various creation options like compression and block-sizes. It seems to be the case for any compression method (packbits, lzw, deflate), and other creation options don't seem to matter. Uncompressed data, or compressed integers work fine, the file size matches gdal_translate very well.
Here is the notebook i used: http://nbviewer.ipython.org/gist/RutgerK/27c4af235035621fb609 I would first all be interested to know if anyone can replicate this behavior? And if there is something i can do to prevent this? I would rather avoid having to run gdal_translate after each file written from Python. I'm running it on Windows 7 64bit. My GDAL version comes from the default Conda repository which contains both bindings and utilities (at least for version 1.11.1). All i could find was this thread from 2010, it seems somewhat similar except that there its about Uint16, for which it works for me: http://osgeo-org.1560.x6.nabble.com/gdal-dev-RE-Compression-using-the-create-method-in-python-and-aggregation-methods-td3747703.html Regards, Rutger -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Filesize-too-large-when-writing-compressed-float-s-to-a-Geotiff-from-Python-tp5208916.html Sent from the GDAL - Dev mailing list archive at Nabble.com. _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev