Same files as the industry standard. Up to 9× faster. Up to 90% less RAM.
Spatial Engine converts and reprojects satellite, aerial, radar and elevation imagery: the heavy, everyday work behind maps, analytics platforms and imagery pipelines. It writes the same GeoTIFF, COG and MRF files as GDAL, the open-source toolkit the industry standardised on.
Built on the Bitruvius codecs (TurboLERC, TurboJXL, TurboWebP, TurboZstd and the rest), not the libraries GDAL links. One command-line engine, macOS and Windows.
Like-for-like medians against GDAL 3.13.3 on the same machine. Benchmark run dated 2026-10-05.
The 60-second version
Every satellite image goes through this step before anyone can use it.
GDAL
The free, open-source toolkit the geospatial industry standardised on for reading, converting and reprojecting imagery. It is the default for these jobs, so it is the benchmark any replacement has to beat, on its own output files.
Convert
Imagery arrives in whatever shape the sensor produced. Before it can stream to a map or feed a model, it is rewritten: compressed, cut into tiles, and given zoomed-out previews. The result is a cloud-ready file (a COG).
Reproject
The Earth is round, maps are flat, and every source uses its own projection. Reprojecting re-maps every pixel onto a common grid so layers line up. It is the most compute- and memory-hungry step in the pipeline.
Memory sets the bill
Cloud servers are priced by memory. A job that needs 3 GB rents a bigger machine, and fits fewer jobs per server, than one that needs 300 MB. Small enough, and it runs on drones, satellites and field kit too.
Watch it
One 1.5 GB satellite image. Same job, same computer.
A Planet SkySat strip, 44,160 by 15,360 pixels, reprojected onto web-map coordinates by both tools. The bars replay the measured times at the same rate, so the gap you see is the gap we measured. Below each, the most memory the job held at any moment.
No cherry-picking
8,452 head-to-heads. GDAL won 3.
Ten production files from ICEYE, Planet and USGS, from a 17 MB preview to a 1.84 GB radar scene. Every compression option both tools support, both file layouts, two tile sizes, every core and a single core, on a Windows workstation and a Mac laptop. Each square below is one of those runs.
The whole test set, end to end.
Add up every run and the gap widens, because the biggest files are where we pull furthest ahead. On the Windows workstation, reprojecting the whole set like for like took GDAL 74 minutes and Spatial Engine under 8.
Speed and memory, together
Faster and leaner, on every file.
Most speed-ups cost memory. This one doesn't. Each dot is one of the ten files on one machine; up and to the right is better on both counts. GDAL is the grey square. No file lands where GDAL would be faster or lighter.
--exact against gdalwarp -et 0), all cores, 256 tiles.
Each dot is one file on one machine: the median over every codec and both containers, against
GDAL on that machine. Speed is GDAL's wall time over ours; memory is our peak over GDAL's.
Source: Spatial Engine vs GDAL brief, 2026-10-05, §4.Memory
GDAL's memory grows with the file. Ours grows incrementally.
GDAL's memory grows with the image: bigger scene, bigger machine. Spatial Engine's grows only incrementally: on the Mac, the two largest files (1.84 GB and 1.51 GB) cost it 376 and 381 MiB at the median, where GDAL climbs past 3 GB. That is the line between a job that fits on a small cloud instance and one that needs a large one.
Smaller instances, more jobs per server
Cloud providers price by CPU and RAM, and memory-heavy machines cost more per CPU. On Windows, GDAL's reprojection of the SkySat strip peaks at 2.8 GB, so every concurrent job needs a 4 GB slot. Ours is 338 MB at the median and 810 MB at worst.
Ten jobs: 3 to 4 GB, not 20 to 30
Ten concurrent GDAL reprojections of 1.5 GB scenes need 20 to 30 GB of RAM. Ten of ours need 3 to 4 GB. For a multi-tenant imagery service, that is the hardware budget.
No out-of-memory failures on the big scene
A pipeline sized for GDAL on 1.5 GB strips breaks on the first 3 GB one. Ours grows incrementally, so the next, larger sensor doesn't force a re-architecture.
Edge and onboard
Drones, satellites, vehicles and field kits run on 4 to 16 GB shared with everything else. A reprojection that wants 3 GB for itself is not deployable there; one that wants 300 MB is.
Two modes, one engine
A low-memory mode GDAL doesn't have, at the same speed.
High-performance mode trades memory for speed. Streaming mode keeps memory low on any size of file. They write identical files, and streaming costs 0 to 6% in time. The engine switches to streaming on its own for large files.
Low-memory mode: 9.03× faster than GDAL in 246 MiB instead of 2,357.
By data type
What it means for the files you have.
Ten files, six kinds of data, from three of the industry's suppliers. The bigger the file, the bigger the lead.
--exact against gdalwarp -et 0), all cores. Translucent: the best median with our default settings, whose grid holds the
projection to 1/8 pixel (gdalwarp's own default tolerance) and is set against GDAL's exact warp, so
it flatters us. The Mac's 512-tile figures paired with GDAL runs on a shared machine; read its
default-grid reach as an upper bound. Medians over every codec and both containers; each machine against its own GDAL. Source: Spatial
Engine vs GDAL brief, 2026-10-05, §4.Satellite and aerial photos
“A 1.5 GB SkySat strip, reprojected exactly, in 4.0 seconds and 233 MB. GDAL: 21 seconds and 2.3 GB.”
Imagery vendors, basemap producers, tile-serving teams. Line measured on Windows x64.
Crop, forest and climate imagery
“A gigabyte of 16-bit analytic imagery reprojected exactly in 1.6 seconds and 201 MB. GDAL wanted 7.3 seconds and 1.8 GB.”
Analytics, agriculture, forestry, ML pipelines. Line measured on Windows x64.
Raw radar for interferometry
“A 1.8 GB complex SAR scene reprojected exactly in 232 MB of RAM. GDAL needs 3.2 GB for the same job, and takes five times as long.”
SAR vendors, interferometry, defence processing chains. Line measured on Windows x64.
Radar that sees through cloud and dark
“A 739 MB SAR amplitude scene reprojected exactly in 450 milliseconds and 316 MB, against GDAL’s 2 seconds and 1.9 GB.”
SAR vendors, maritime and defence analytics. Line measured on macOS, Apple M3 Max.
3D terrain and flood models
“Same DEM, zero error, 29 MB instead of 71 with lossless LERC v6. GDAL reads it.”
DEM, DSM, bathymetry, hydrology and flood modelling. Line measured on Both machines.
Preview images, by the thousand
“Even a 17 MB quicklook reprojects exactly twice as fast, in half the memory.”
Browse, tasking feedback and quicklook catalogues. Line measured on Both machines.
Chips: like-for-like reprojection, median of every codec for that file, and peak RAM as a fraction of GDAL's, on each machine.
Every codec
Whatever compression you use, it's faster.
Imagery is stored with one of a dozen compression schemes, each with its own trade-off between size and speed. Customers don't switch theirs to suit a vendor, so we measured every one both tools support. The weakest cell on the board is still 1.24× faster.
| Codec | Windows x64 | macOS | ||||
|---|---|---|---|---|---|---|
| Convert | Convert, low-memory | Reproject | Convert | Convert, low-memory | Reproject | |
| LERC v4 | 3.05× 0.91× RAM | 2.89× 0.35× RAM | 4.81× 0.34× RAM | 3.25× 0.93× RAM | 3.17× 0.50× RAM | 4.10× 0.22× RAM |
| LERC v4 + Deflate | 2.94× 0.87× RAM | 3.10× 0.39× RAM | 4.00× 0.38× RAM | 2.39× 0.92× RAM | 2.44× 0.61× RAM | 3.01× 0.22× RAM |
| LERC v4 + ZSTD | 2.66× 1.07× RAM | 2.62× 0.57× RAM | 4.27× 0.62× RAM | 2.72× 1.05× RAM | 2.57× 0.76× RAM | 3.64× 0.30× RAM |
| Deflate | 2.75× 0.92× RAM | 3.18× 0.44× RAM | 3.36× 0.35× RAM | 2.13× 0.97× RAM | 2.37× 0.61× RAM | 3.12× 0.21× RAM |
| ZSTD | 2.18× 0.96× RAM | 2.31× 0.37× RAM | 3.87× 0.27× RAM | 2.50× 0.94× RAM | 2.46× 0.45× RAM | 3.21× 0.24× RAM |
| LZW | 2.99× 0.96× RAM | 3.14× 0.40× RAM | 4.01× 0.31× RAM | 2.61× 0.96× RAM | 2.57× 0.65× RAM | 3.09× 0.21× RAM |
| LZMA | 6.72× 0.88× RAM | 6.37× 0.44× RAM | 5.93× 0.40× RAM | 5.02× 0.90× RAM | 4.95× 0.47× RAM | 4.39× 0.37× RAM |
| PackBits | 2.50× 1.01× RAM | 2.81× 0.52× RAM | 4.65× 0.34× RAM | 2.98× 1.02× RAM | 3.26× 0.65× RAM | 3.97× 0.22× RAM |
| Uncompressed | 2.49× 1.04× RAM | 2.88× 0.56× RAM | 4.75× 0.25× RAM | 3.00× 1.06× RAM | 4.00× 0.62× RAM | 4.49× 0.21× RAM |
| JPEG | 4.62× 0.90× RAM | 5.17× 0.44× RAM | 4.23× 0.25× RAM | 3.26× 0.95× RAM | 3.34× 0.41× RAM | 3.50× 0.18× RAM |
| WebP | 3.83× 0.88× RAM | 3.82× 0.16× RAM | 4.42× 0.11× RAM | 1.24× 0.92× RAM | 1.25× 0.22× RAM | 2.24× 0.12× RAM |
| WebP lossless | 4.49× 0.83× RAM | 4.37× 0.29× RAM | 8.49× 0.13× RAM | 4.00× 0.88× RAM | 3.91× 0.32× RAM | 5.52× 0.12× RAM |
| JPEG XL | 5.25× 0.85× RAM | 5.56× 0.54× RAM | 4.66× 0.48× RAM | 3.37× 0.82× RAM | 3.31× 0.47× RAM | 3.31× 0.35× RAM |
The big numbers
Where the gap gets enormous.
Everything above is a like-for-like median, the figure we stand behind in diligence. These are the largest gaps in the same run, each labelled with exactly what it measures.
Elevation, head to head
Faster to write, half the RAM to reproject, 41% of the size.
Elevation models drive flood, line-of-sight and 3D work, and they store exact decimal heights. Here is one, run through both tools on every axis that costs money. Writing the very same LERC v4 file GDAL writes, we finish first. Reprojecting it, we use under half the memory. And our default LERC v6, which GDAL reads but cannot write, stores the same heights with zero error in 41% of the space.
Across every codec on this file: writing 2.33×–2.84× faster in low-memory mode; reprojecting 2.86× faster at 0.49× GDAL's memory.
Same codec, same size: our lossless output matches GDAL's bytes at the median. The gap is LERC v6, which GDAL reads but cannot write.
File layouts
- GeoTIFF
- Cloud-Optimized GeoTIFF (COG), with previews built in the same pass
- MRF (Esri and NASA tile stores)
- BigTIFF past 4 GiB
Codecs
LERC v4 / v5 / v6 · LERC + Deflate · LERC + ZSTD · JPEG XL · WebP (lossy and lossless) · JPEG · LZMA · ZSTD · Deflate · LZW · PackBits · PNG (into MRF) · Uncompressed
LERC v6 is the default: the version Esri's current library writes, which GDAL reads but cannot write. Lossless outputs are the same size as GDAL's, 1.000× at the median.
Drops into the pipeline
Two commands change; everything else stays on GDAL. Every output opens in GDAL, lossless outputs reproduce the source checksums, and macOS and Windows write the same output. Licensed offline, with no network call.
How this was measured
- Machines: Apple M3 Max (16 cores) and Intel Core Ultra 9 285HX (24 logical processors), each compared with GDAL 3.13.3 on the same machine. The two are never divided into one ratio.
- One process against one process, wall clock to wall clock, writing the same file layout at the same tile size with the same codec settings. Peak memory is the process's maximum resident set.
- Like for like means reprojection exact to the pixel on both sides (
--exactagainstgdalwarp -et 0), LERC v4 against GDAL's LERC v4, and lossless JPEG XL at effort 5 on both sides. "Our default settings" hold the projection to 1/8 pixel, gdalwarp's own default tolerance, and are compared with GDAL's exact run; they are always labelled. - Windows figures for every codec except JPEG XL come from the build before an allocator change in the next release, which measured 3% faster and used 13% more peak memory at the median on all cores.
- Measured on macOS and Windows only; no Linux numbers are published until a Linux run exists. On the Mac, reprojection at 512-pixel tiles and JPEG XL reprojection paired with GDAL runs on a shared machine, so read those ratios as upper bounds. Our lossless JPEG XL files are 3%–5% larger than GDAL's at the same effort.
- Speed is GDAL's wall time divided by ours; memory is our peak divided by GDAL's. Source: Spatial Engine vs GDAL brief and golden-corpus report, dated 2026-10-05.
Bring five of your files.
A pilot runs both tools on your own data, on your own machine, in a day: same file layout, same codec, same grid. You keep the numbers.
Spatial Engine has its own license, and encoding also needs a codec license. about pricing.
GDAL is an open-source project, named solely to identify the software compared. Esri, ArcGIS and LERC are trademarks of Environmental Systems Research Institute, Inc. Planet, PlanetScope and SkySat are trademarks of Planet Labs PBC; ICEYE is a trademark of ICEYE Oy; the elevation sample is USGS 3D Elevation Program data. These names identify the sample files measured, and no affiliation, sponsorship, endorsement or customer relationship is implied. Apple, macOS, Intel, Intel Core and Windows are trademarks of their respective owners and identify the test machines. Performance comparisons reflect our own measurements under the stated methodology; results vary by workload and hardware. Full third-party notices: Attributions.