<div dir="ltr"><div><br><br>On Thu, Oct 26, 2017 at 7:23 PM, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br>><br>> On jeudi 26 octobre 2017 18:57:10 CEST Markus Neteler wrote:<br>><br>> > On Thu, Oct 26, 2017 at 9:25 AM, Markus Metz<br>><br>> ><br>><br>> > <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>> wrote:<br>><br>> > > On Wed, Oct 25, 2017 at 10:40 PM, Markus Neteler <<a href="mailto:neteler@osgeo.org">neteler@osgeo.org</a>> wrote:<br>><br>> > >> Hi devs,<br>><br>> > >><br>><br>> > >> while playing with the SRTM 30m world I see that there is a difference<br>><br>> > >> of 66GB in size between LZ4 (larger) and DEFLATE (smaller). While this<br>><br>> > >> is not a surprise I was wondering if LZW compression could be brought<br>><br>> > >> back. AFAIK the license issue is gone for a while and indeed GRASS got<br>><br>> > >> a special permit back in 1988 according to the old source code.<br>><br>> > >><br>><br>> > >> Would that make sense?<br>><br>> > ><br>><br>> > > You could test with compress (LZW) and gzip (DEFLATE based on LZ77) if<br>><br>> > > that<br>><br>> > > would make sense.<br>><br>> > ><br>><br>> > > Implementation would be a bit of an effort: either adapt from the source<br>><br>> > > code of compress or from GDAL's LZW compression for Tiff.<br>><br>> ><br>><br>> > I thought to remember that the LZW compression was in libgis some<br>><br>> > decades ago but did not find any trace so far.<br>><br>> > At that point I happily abandon this idea - no need to waste energy here :-)<br>><br>>  <br>><br>> Another option would be to consider the zstd / zstandard compression method<br>><br>> ( <a href="https://github.com/facebook/zstd">https://github.com/facebook/zstd</a> ), that has roughly the compression ratio of DEFLATE / LZ77 with a compression and decompression speed 3 or 4 times faster. This is in my todo list of things to experiment as a libtiff compression method.<br>><br>>  <br>><br>> Zstd has been added recently as a compression method in the Linux kernel:<br>><br>> <a href="https://www.phoronix.com/scan.php?page=news_item&px=ZSTD-Linux-Kernel-Image">https://www.phoronix.com/scan.php?page=news_item&px=ZSTD-Linux-Kernel-Image</a><br>><br></div>Strong arguments for zstd! It seems that zstd is also adopted by other projects, and also available for RHEL 7 via EPEL.<br><br>Some quick test gives me zstd compression speed a bit slower than lz4 and zstd compression ratio a bit better than zlib's deflate, i.e. with about the speed of lz4 you can get compression ratio a bit better than deflate, that's great! Regarding compression ratio, zstd with ultra settings can get close to bzip2, but is then much slower than bzip2 with zstd's memory usage exploding.<br><br>The zstd API is similar to the API of zlib/lz4/bzip2, that means adding zstd to GRASS could be done by cloning e.g. the GRASS interface to lz4. <br><div><br></div><div>Markus M<br></div><div>>  <br>><br>> Even<br>><br>>  <br>><br>> --<br>><br>> Spatialys - Geospatial professional services<br>><br>> <a href="http://www.spatialys.com">http://www.spatialys.com</a><br><br></div></div>