Same TIFF LZW. Twice as fast on real imagery.
LZW is inside a large share of GeoTIFFs and satellite archives, and every GDAL, rasterio, QGIS, Pillow and ImageMagick read of it goes through libtiff's 1990s LZW code. TurboLZW plugs into libtiff in its place: the same files, in memory-safe code, with no code changes.
Registered through libtiff's own codec plug-in API for TIFF Compression=5. libtiff reads every file TurboLZW writes, and TurboLZW reads every file libtiff writes, to the same pixels.
The trade, up front: at 4 KB tiles libtiff reads faster (0.85×). Every tile size is in the chart below.
The 60-second version
Decades of imagery are stored as LZW, and it is decoded on every read.
LZW in TIFF
Lossless compression that has been in TIFF for decades. Satellite products, aerial surveys and GIS archives still ship with it.
libtiff
The C library under GDAL, rasterio, QGIS, Pillow and ImageMagick. Its LZW code predates modern CPUs and uses none of their vector instructions.
Decoded on every read
Every tile served, every conversion and every analysis job decompresses the LZW first, so its speed is paid for on every read, in C code that parses untrusted files.
A memory-safe drop-in
TurboLZW registers with libtiff as its LZW codec. Every program above uses it without a rebuild, reading and writing the same files, faster on real imagery.
What it means for the bill
Half the decode time, with nothing to migrate.
The measured figures, translated.
Illustrative, from the measured figures. A pilot measures yours.
Every tile size
Every tile size, including the one we lose.
Read speed on Planet, ICEYE SAR and Hurricane Harvey flood imagery, as a multiple of libtiff 4.7.1 on the same compressed bytes. The dashed line is parity; bars past it mean TurboLZW is faster.
At 4 KB tiles libtiff is faster (0.85×). GDAL and cloud-optimized GeoTIFF readers work in 64 KB tiles and larger.
On synthetic test buffers, 5 of 12 read faster (1.02× to 1.18×). The 7 slower ones are small and mid-size all-zero and random-noise buffers, down to 0.56×.
Already at work
The LZW inside Spatial Engine.
Spatial Engine, our imagery engine, converts and reprojects imagery, and TurboLZW reads and writes every LZW file inside it. Writing LZW GeoTIFFs, it finishes several times sooner than GDAL.
See Spatial EngineSpatial Engine against GDAL 3.13.3, LZW output on both sides, median over the whole test set on the same machine; Windows leads. Whole-pipeline figures, engine and codec together. The Mac reprojection figure is an upper bound.
Many strips, one call
Every core, without writing the threading.
libtiff decodes one strip per call, so every program that wants more than one core writes its own threading. TurboLZW takes the whole batch in one call and spreads it across every core.
Drops into the pipeline
A library swap. Not a migration.
- - libtiff's own plug-in API. TurboLZW registers as the LZW codec through TIFFRegisterCODEC, the extension point libtiff provides, not a symbol override. Load it with LD_PRELOAD on Linux, DYLD_INSERT_LIBRARIES on macOS, or a DLL beside the program on Windows.
- - Same files, both ways. Standard TIFF LZW (Compression=5): what TurboLZW writes, libtiff decodes to the original pixels, and what libtiff writes, TurboLZW decodes to the same pixels libtiff does. Checked in both directions on every release.
- - Reversible. Remove the plug-in and libtiff's own LZW is back. Nothing in your files changes.
- - Memory-safe. The LZW code that parses untrusted files is no longer C.
- - Vector backends for AVX2 on Intel and AMD and NEON on ARM, with a portable fallback, picked at startup and checked to produce identical output.
How this was measured
- Against libtiff 4.7.1 on an Intel Core Ultra 9 (Arrow Lake), one core unless stated, TurboLZW v1.0.10 (build 563319c).
- Real imagery: raw compressed strips read once from Planet, ICEYE SAR and Hurricane Harvey flood imagery files; both decoders then decode the identical bytes. Synthetic: all-zero, sequential and random buffers from 4 KB to 1 MB.
- libtiff keeps the file open across reads, as GDAL does. Write tests subtract libtiff's TIFF-container cost (about 14.5 microseconds) so only the compression is compared.
- Every TurboLZW output decodes through libtiff to the original pixels, and every libtiff output decodes through TurboLZW to the same pixels.
Bring five of your LZW TIFFs.
A pilot runs both libraries on your own files, on your own machine, inside the tools you already use. You keep the numbers.
TurboLZW is licensed through the Bitruvius Developer Hub and ships as compiled binaries.
Comparisons on this page reference the LZW codec in libtiff, distributed by its maintainers under the libtiff (MIT-style) license; that name, and references to GDAL, QGIS, ImageMagick, Pillow, and rasterio, are used solely to identify the implementations and ecosystems being compared or interoperated with, and no affiliation, sponsorship, or endorsement is implied. The core LZW patent (U.S. Patent No. 4,558,302) expired on June 20, 2003, and its international counterparts through 2004; the algorithm is freely usable. TurboLZW is an independent implementation. Performance comparisons reflect our own measurements under the stated methodology; results vary by workload and hardware. Full third-party notices: Attributions.