Same files as the industry standard. Up to 9× faster. Up to 90% less RAM.
Every satellite image is written once and read thousands of times. Bitruvius Spatial Engine does both at blazing speed, blasting past GDAL, the toolkit the industry runs on, in a fraction of the memory. It writes the same GeoTIFF, COG and MRF files, so nothing downstream has to change.
Built on the Bitruvius codecs (TurboLERC, TurboJXL, TurboWebP, TurboZstd and the rest), not the libraries GDAL links. One command-line engine, macOS and Windows.
Write once
Read forever
Against GDAL 3.13.3 on the same machine. Writing: like-for-like medians from the run dated 2026-10-05; GDAL finished first in 3 of 8,452. Reading: geometric means from the run dated 2026-10-10; GDAL finished first in 10 of 7,648.
The 60-second version
Every image lives two lives.
It is written once, then read for years. GDAL sits under both, so both run up your cloud bill every day. Spatial Engine takes over both, on the same files.
Write once: a satellite's raw scene goes through Spatial Engine and becomes a new tiled file, 4.44× faster than GDAL. Read forever: that file is read again and again by maps, AI models and tile servers, 2.85–3.39× faster, every read.
GDAL
The free, open-source toolkit the industry standardised on. It does both lives of every image today, so it is the bar any replacement has to clear, on its own files.
Write once
Imagery lands in whatever shape the sensor produced. Before anyone can use it, it is written into a cloud-ready file: compressed, cut into tiles, often reprojected onto a common map grid. That happens once per image.
Read forever
Then the reads start: every map someone pans, every model that trains, every tile a server sends. The same file is read thousands of times, for as long as it exists.
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.
Who runs it
Everyone who turns imagery into a product runs both jobs, every day.
Satellite operators, map makers, defence, AI teams and cloud platforms all write imagery once and read it endlessly, and most of them do it on GDAL today. Spatial Engine drops in under the same files, so it sells into every one of them.
Satellite and aerial operators
WriteEvery downlinked scene becomes a cloud-ready product, on deadline.
ReadEvery customer download, browse image and archive search.
Map and basemap platforms
WriteMosaics and tile pyramids rebuilt each time new imagery lands.
ReadEvery tile a map serves, to every user, every day.
Defence and intelligence
WriteRadar and optical scenes processed fast, often on small machines in the field.
ReadAnalysts and models pulling the same scenes around the clock.
AI and analytics teams
WriteTraining sets cut into tiles and lined up on one grid.
ReadEvery training run reads every tile again, epoch after epoch.
Cloud and data platforms
WritePublic and commercial archives converted for hosting.
ReadMillions of requests against the same files, billed by the second.
One engine, every segment
Same two jobs. Same incumbent underneath. Same files out.
No segment needs its own product: what wins for a satellite operator wins for a map platform and an AI team, on the files they already have.
Chapter 1 · Write once
Write it once.
4.44× faster.
Converting and reprojecting is the heavy lifting: it decides how fast new imagery reaches your customers and how big a machine it needs. Spatial Engine does it in as little as 10% of GDAL's memory, on GDAL's own files, and won 8,449 of 8,452 head-to-heads.
WriteWatch it
One 1.5 GB satellite image. GDAL: 21 seconds. Spatial Engine: 4.
A Planet SkySat strip, 44,160 by 15,360 pixels, reprojected onto web-map coordinates and written to a new file 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.
WriteNo 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: 74 minutes for GDAL, under 8 for Spatial Engine.
Add up every like-for-like run on the Windows workstation and the gap widens, because the biggest files are where we pull furthest ahead.
WriteSpeed 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.WriteMemory
GDAL's memory grows with the file. Ours barely moves.
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.
WriteTwo 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.
WriteBy 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: reproject and write, like for like, median of every codec for that file, and peak RAM as a fraction of GDAL's, on each machine.
WriteEvery 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 and write | Convert | Convert, low-memory | Reproject and write | |
| 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 |
WriteThe 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 biggest gaps in the same run, smallest to largest, each with exactly what it measures.
A whole archive, reprojected and written
Every matched exact cell summed end to end on Windows: 473 s against GDAL’s 4,440 s. Like for like.
A 1.5 GB satellite strip into a cloud-ready COG
Low-memory mode on Windows, best tile-size median, at 0.13×–0.19× of GDAL’s peak memory.
The same strip, reprojected onto a web map
Our default settings (accurate to 1/8 pixel) against GDAL’s exact warp, Windows: 1.5 s against 19.9 s, in 379 MiB against 2,344.
A 1.49 GB mosaic in JPEG XL, the newest compression
The 1.49 GiB visual mosaic on Windows: 10.2 s against that machine’s GDAL at 257.8 s. Both lossless, both effort 5.
PNG into MRF (Meta Raster Format), all cores
GDAL’s MRF driver compresses on one thread; ours uses every core. Engine for engine, one thread each, it is 4.85×.
WriteElevation, 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.
Chapter 2 · Read forever
Read it forever.
2.85–3.39× faster, every single time.
Reads never stop. Every map view, model run and tile request opens a file and pulls its pixels out. Spatial Engine does it faster on every codec we measured, hands back the same pixels as GDAL, and uses 20–38% of its memory.
gdalwarp -et 0. Both jobs hand back uncompressed pixels, so no
compressed file is written. Source: Spatial Engine 0.1.7 read report, 2026-10-10.7,648 head-to-head reads. GDAL finished first in 10.
Every codec, both file layouts, two tile sizes, one core and every core, both of our modes, on the same Windows workstation and Mac laptop. Each run was timed once. GDAL never beat both of our modes on the same file. Six of its 10 came on the smallest file, a 17 MB radar preview that both tools read in under a quarter of a second; the other four were single slow timings on the Mac that ran flat when timed again side by side. Every read was checked against GDAL's pixels: 0 mismatches.
| Codec | Windows x64 | macOS | ||
|---|---|---|---|---|
| Read | Read and reproject | Read | Read and reproject | |
| GeoTIFF | ||||
| Deflate | 2.11× to 2.44× | 2.91× to 3.51× | 2.03× to 2.10× | 2.69× to 3.03× |
| JPEG | 2.39× to 3.00× | 2.90× to 3.54× | 2.02× to 2.46× | 2.84× to 3.26× |
| JPEG XL | 2.07× to 2.74× | 2.56× to 2.78× | 1.42× to 2.57× | 1.88× to 2.49× |
| LERC v4 | 1.87× to 2.02× | 2.90× to 3.66× | 1.94× to 2.12× | 2.82× to 3.18× |
| LERC v4 + Deflate | 1.73× to 1.97× | 2.71× to 3.46× | 1.75× to 1.84× | 2.63× to 2.85× |
| LERC v4 + ZSTD | 1.79× to 2.08× | 2.79× to 3.53× | 1.93× to 2.00× | 2.76× to 3.01× |
| LZMA | 2.93× to 3.17× | 2.89× to 3.04× | 2.48× to 2.95× | 2.54× to 2.73× |
| LZW | 2.31× to 2.49× | 3.04× to 3.53× | 2.45× to 2.53× | 2.89× to 3.29× |
| Uncompressed | n/a | 3.14× to 3.69× | n/a | 2.97× to 3.48× |
| PackBits | 2.27× to 2.61× | 3.10× to 3.75× | 2.30× to 2.35× | 2.96× to 3.47× |
| WebP | 2.21× to 2.95× | 3.44× to 4.12× | 1.39× to 1.59× | 3.16× to 3.44× |
| WebP lossless | 2.27× to 3.12× | 3.19× to 4.20× | 1.64× to 1.67× | 3.03× to 3.22× |
| ZSTD | 2.15× to 2.59× | 3.11× to 3.75× | 2.05× to 2.18× | 2.89× to 3.27× |
| MRF | ||||
| Deflate | 3.16× to 3.34× | 4.09× to 4.49× | 3.82× to 4.13× | 4.10× to 4.47× |
| JPEG | 3.20× to 3.36× | 3.71× to 4.03× | 4.34× to 4.74× | 3.83× to 4.16× |
| LERC v4 | 2.58× to 2.71× | 3.73× to 4.21× | 3.64× to 3.93× | 3.99× to 4.34× |
| PNG | 3.72× to 3.88× | 4.21× to 4.68× | 5.15× to 5.54× | 4.16× to 4.50× |
What it does to the bill
Save once on every image. Then save again every time anyone opens it.
Write once
Paid once per image
The whole test set, reprojected and written like for like on one Windows workstation: 9.39× faster end to end.
To reproject and write a 1.84 GB radar scene. Smaller machines, more jobs per server.
Read forever
Collected on every read
Than GDAL, on every read, every core, both machines.
At the median, every core. The same pixels GDAL hands back.
Same files in, same files out, so switching is a swap, not a migration. The write saving lands once per image. The read saving lands every time anyone opens it, for as long as the file exists.
File layouts
- GeoTIFF
- Cloud-Optimized GeoTIFF (COG), with previews built in the same pass
- MRF (Meta Raster Format)
- 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
Write once: converting and reprojecting into new files
- 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.
Read forever: reading files back
- The published Spatial Engine 0.1.7 release against GDAL 3.13.3, on
the same two machines and ten files, one timing per run. Both read jobs write uncompressed tiles,
so no compression is timed on either side. Reading onto another grid is exact against
gdalwarp -et 0, and leaves out the two files whose grids the tools set up differently. Read speeds are geometric means; read memory is the median of our peak over GDAL's. Deflate and PNG are read through standard open-source decoders inside the engine; every other codec is a Bitruvius codec. Source: Spatial Engine read report, dated 2026-10-10.
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.