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


GRASS trunk has also already implemented ztsd as a raster compression

And it's available for testing already in the OSGeo4W-winGRASS trunk daily

(1) https://grass.osgeo.org/grass75/manuals/r.compress.html

best regards
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
gdal-dev mailing list

Reply via email to