<div dir="ltr"><div><br><br>On Fri, Oct 27, 2017 at 10:44 PM, Markus Metz <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>> wrote:<br>><br>><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>> 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></div>Some more tests:<br>corine land cover 250 meter, relatively small, easy to compress Byte type<br>LZ4: 33 sec, 54 MB<br>ZLIB level 1: 36 sec, 39 MB<br>ZSTD level 3: 34 sec, 29 MB<br><br>GMTED2010 for the corine region as float, difficult to compress<br>LZ4: 27 sec, 3.1 GB<br>ZLIB level 1: 129 sec, 2.7 GB<br>ZSTD level 3: 38 sec, 2.8 GB<br><br>GMTED2010 for the corine region as integer, easy to compress but a lot of data<br>LZ4: 38 sec, 1.4 GB<br>ZLIB level 1: 73 sec, 993 MB<br>ZSTD level 3: 53 sec, 982 MB<br><br>attempting maximum compression of GMTED2010 as integer<br>ZLIB level 9: 735 sec, 945 MB<br>ZSTD level 19: 485 sec, 846 MB<br>BZIP2: 273 sec, 618 MB<br><br>With easy to compress data, ZSTD is faster and compresses better than ZLIB. With difficult to compress data (floating point), ZSTD is at least 3x faster than ZLIB with slightly worse compression than ZLIB, but still better than LZ4. <br><div><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><div><br></div><div>ZSTD seems to be an improvement over ZLIB: it is always faster and most of the time compression ratio is higher. I see the biggest advantage for difficult to compress data where ZSTD is considerably faster than ZLIB, with similar compression. Therefore I think adding ZSTD to GRASS would be a good idea.<br></div><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>