Even Rouault-2 wrote > Hi, > > I've just pushed in libtiff upstream, and its internal copy in GDAL, > support for zstandard/ > zstd compression [1], and the appropriate changes in the GDAL GeoTIFF > driver. > This requires building libtiff (or GDAL with its internal libtiff copy) > against libzstd >= 1.0 > My findings are that single-core compression is at least twice faster with > zstd than with > deflate, for equivalent or better compression rate. Decompression is a bit > faster, but not > that significantly. > > So a compelling use case for zstd is potentially in complex processing > chains where you > have many intermediate internal products. At that point of adoption, I'd > not recommend it > for consumer-facing products. > > Even > > [1] https://github.com/facebook/zstd
fyi GRASS trunk has also already implemented ztsd as a raster compression option.(1) And it's available for testing already in the OSGeo4W-winGRASS trunk daily builds. (1) https://grass.osgeo.org/grass75/manuals/r.compress.html ----- best regards Helmut -- Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev