LERC compression benchmarks
Benchmarks
After looking at how LERC compression works last week, I compared the compression ratio and read/write speed for different LERC MAX_Z_ERROR
values against other compression methods. I ran the analysis on my desktop computer (which has an SSD) and did the reading/writing with rasterio 1.2.6 (which uses gdal 3.3.0).
I used the file Copernicus_DSM_COG_10_S43_00_E171_00_DEM.tif
: a tile of the 30m Copernicus DEM containing elevation values for New Zealand’s West Coast. The file is 3600x3600 pixels, is in float32 format, has a 512x512 internal block size, and is about 56MB uncompressed.
The results roughly align with @kokoalberti’s geoTIFF compression benchmarks. 10 runs were done for each compression method, and the median was taken. Higher is better for all measures.
Algorithm | Max error | Write speed | Read speed | Compression ratio |
---|---|---|---|---|
none | 0 | 1087 | 3217 | 1.0 |
int16 | 0 | 1577 | 6700 | 2.0 |
int16 + ZSTD | 0 | 560 | 1815 | 4.4 |
ZSTD | 0 | 519 | 957 | 1.5 |
ZSTD (predictor 3) | 0 | 224 | 367 | 2.0 |
Deflate | 0 | 33 | 253 | 1.6 |
Deflate (predictor 3) | 0 | 35 | 216 | 2.0 |
LERC | 1e-5 | 315 | 473 | 1.9 |
LERC | 1e-4 | 325 | 482 | 2.2 |
LERC | 1e-3 | 337 | 492 | 2.7 |
LERC | 1e-2 | 347 | 490 | 3.4 |
LERC | 1e-1 | 361 | 511 | 4.6 |
LERC | 1.0 | 377 | 519 | 7.0 |
Some observations
- Even with a small
MAX_Z_ERROR
of 0.00001, LERC matches DEFLATE compression ratio and massively outperforms in read/write speed. - Compared to ZSTD, LERC achieves similar compression with
MAX_Z_ERROR
of 0.00001, though read and write speed are faster with ZSTD by about 2x for all error values. - If you’re converting floating point data to integers and storing as a compressed geotiff, consider using LERC instead with an error of 0.5: the compression ratio is better, though speeds are slower.
- Increasing
MAX_Z_ERROR
has a big impact on compression ratio. LargerMAX_Z_ERROR
also slightly improves read and write speeds.
Stacked LERC compression
LERC can be stacked with other compression algorithms: first the data is compressed using LERC, then that result is compressed with a lossless algorithm like ZSTD or Deflate.
The idea is that the output of LERC compression is integers with high autocorrelation, so there is still some signal that can be used for compression.
In practice, I don’t recommend this. Firstly due to support: LERC already has limited support in geo software, and stacked compression even more so. Stacked LERC compression isn’t supported by tifffile
, and is only recently supported by rasterio
.
But the main reason I don’t use stacked LERC compression is that it doesn’t really help that much. Read and write speeds are strictly worse than LERC alone: for this benchmark LERC+ZSTD is only about 5% slower, while LERC+Deflate was a twice as slow to read and write. Stacked compression does result in smaller files but not by much: LER+ZSTD compressed about 2% smaller than LERC alone, while LERC+Deflate managed 4% averaged across multipole MAX_Z_ERROR
levels.
Max error → | 1 | 1e-1 | 1e-2 | 1e-3 | 1e-4 | 1e-5 |
---|---|---|---|---|---|---|
Algorithm | ||||||
lerc | 377 | 361 | 347 | 337 | 325 | 315 |
lerc_deflate3 | 138 | 116 | 96 | 81 | 69 | 60 |
lerc_zstd3 | 344 | 325 | 304 | 282 | 270 | 253 |
Max error → | 1 | 1e-1 | 1e-2 | 1e-3 | 1e-4 | 1e-5 |
---|---|---|---|---|---|---|
Algorithm | ||||||
lerc | 519 | 511 | 490 | 492 | 482 | 473 |
lerc_deflate3 | 379 | 326 | 311 | 283 | 259 | 238 |
lerc_zstd3 | 478 | 498 | 494 | 489 | 477 | 468 |
Max error → | 1 | 1e-1 | 1e-2 | 1e-3 | 1e-4 | 1e-5 |
---|---|---|---|---|---|---|
Algorithm | ||||||
lerc | 7.00 | 4.61 | 3.42 | 2.71 | 2.25 | 1.92 |
lerc_deflate3 | 7.49 | 4.70 | 3.46 | 2.74 | 2.27 | 1.94 |
lerc_zstd3 | 7.27 | 4.63 | 3.42 | 2.71 | 2.25 | 1.93 |