Bitruvius Imagery & 3D Suite / TurboJXL Track B - Drop-in Coming Soon

Built for tiled geospatial imagery.

An encode-first, memory-safe JPEG XL codec for next-generation 256² and 512² tile pyramids — web maps, COG overviews, tile servers. You encode each tile once at ingest and serve it forever, so encode is the moat: smaller files than cjxl's fast preset, and orders of magnitude faster than the slow preset that matches its size. Bit-exact with libjxl 0.11.2 both directions, with the entire C/C++ decoder vulnerability class eliminated at compile time.

Drop-in for libjxl 0.11.2 (cjxl / djxl). SIMD backends: AVX2, NEON, WASM. No C toolchain on your CI runners or customer build farms.

Headline

Encode once. Serve forever.

The number that matters first is correctness: 285 / 285 samples of libjxl's own labeled corpus round-trip bit-exact in both directions — TurboJXL-encode → djxl-decode and cjxl-encode → TurboJXL-decode — at three effort tiers and on both AVX2 and NEON. On that contract TurboJXL is an encode-first codec for the tiled-geospatial pipeline, and it sits on the corner of cjxl's size/speed frontier: it emits smaller files than cjxl's fast -e1 preset (RGB-ortho & SAR 2–3%, AI-inference masks up to 28%), while encoding ~42–71× faster per core than the glacial -e7 effort cjxl needs just to reach TurboJXL's compression — up to ~300× on large RGB tiles. Both wins hold on AVX2 and NEON. And because the parser is memory-safe, the buffer-overflow / use-after-free vulnerability class that haunts every C/C++ image codec is gone at compile time.

Encode speed · per core · vs cjxl[e=7]
~42–71× faster

To reach TurboJXL's size, cjxl must drop to effort 7 — glacial at 0.3–2.6 MP/s. TurboJXL sustains 60–420 MP/s per core (up to ~300× faster on large RGB tiles).

Bit-exact gate
285 / 285

Cross-codec round-trip, both directions, both ISAs, e=1 / e=3 / e=7. The bench fails non-zero on any pixel mismatch.

Size vs cjxl[e=1] · cjxl's fast preset
2–28% smaller

Smaller and faster than cjxl's fast preset: RGB-ortho & SAR 2–3% on every tile; AI-inference masks 14–28%. Deterministic — bytes in / bytes out.

In-browser tile decode
No plugin, no fork

Decodes JXL tiles directly in the browser as sandboxed WebAssembly — the web-map / COG path. Race it head-to-head against libjxl-WASM in the demo below.

Decoder attack surface
Memory-safe

A memory-safe bitstream parser eliminates the buffer-overflow / UAF / OOB CVE class of C/C++ image decoders — at compile time, with no sandbox tax.

Toolchain
Zero C deps

Memory-safe — no libjxl, no C compiler, no cmake. One cargo build on every target.

Runs anywhere

And it decodes in any browser.

Decode is the commodity half — libjxl's C++ decoder is mature, and memory-safe TurboJXL matches it per core while adding memory safety and a zero-fork WASM path. Race TurboJXL against libjxl-WASM on the same tiles in your own browser — geospatial types at 256²/512², lossless or visually-lossless, in Chrome or Safari — and see the real per-tile decode on your machine.

Image Codec Race — TurboJXL vs libjxl — live in your browser open full screen ↗
loading demo…

Storage ROI

Smaller than cjxl's fast preset — on every geospatial type.

Output size vs cjxl --effort=1 (libjxl's fast-lossless preset) at default TurboJXL settings — and TurboJXL is faster than -e1 too, so this is a win on both axes against the same operating point. RGB orthophotos and SAR quicklook run 2–3% smaller across every tile size; satellite-derived AI inference masks — high-run mask content — compress 14–28% smaller than cjxl.

Smaller files than cjxl[e=1] — every domain, every tile

AI inference masks RGB orthophoto SAR quicklook
0.0%5.0%10.0%15.0%20.0%25.0%30.0%0% = same size as cjxlAI inference masks @ 256²: 27.8% smaller than cjxl[e=1]28RGB orthophoto @ 256²: 3.4% smaller than cjxl[e=1]3SAR quicklook @ 256²: 3.4% smaller than cjxl[e=1]3256²AI inference masks @ 512²: 19.1% smaller than cjxl[e=1]19RGB orthophoto @ 512²: 2.8% smaller than cjxl[e=1]3SAR quicklook @ 512²: 2.3% smaller than cjxl[e=1]2512²AI inference masks @ 1024²: 13.7% smaller than cjxl[e=1]14RGB orthophoto @ 1024²: 3.1% smaller than cjxl[e=1]3SAR quicklook @ 1024²: 2.0% smaller than cjxl[e=1]21024²RGB orthophoto @ 2048²: 3.3% smaller than cjxl[e=1]3SAR quicklook @ 2048²: 1.5% smaller than cjxl[e=1]22048²Tile size

Per-domain geometric mean on the ript geospatial corpus, default TurboJXL vs cjxl -e1 — committed parquet, 344 samples with both round-trip directions gated. Size is deterministic (bytes in, bytes out), so these ratios hold on any machine. Opt in to the learned-tree path to match cjxl's slow -e7 size while staying several× faster.

Where we dominate

Single-band geospatial is the sweet spot.

AI inference masks, 256²
28% smaller

High-run satellite-derived mask content compresses up to −28% vs cjxl[e=1] at 256² — the strongest size cell in the corpus, and exactly the tile size tile servers ship.

SAR & mask encode
Fast-lossless speed

One fixed operating point at 60–80 MP/s reaches near-max compression — no slow effort sweep, no per-tile retuning across a pyramid of thousands of tiles.

Why switch

A library swap. Not a migration.

  • - Built for the tile pyramid: 256² / 512² geospatial tiles encode ~42–71× faster per core than the glacial -e7 effort cjxl needs to match their size (up to ~300× on large RGB tiles), and decode in the browser as sandboxed WebAssembly — no native plugin, no subprocess.
  • - Smaller than cjxl's fast -e1 preset on every geospatial type: RGB-ortho & SAR 2–3% across every tile size, AI-inference masks 14–28% — default settings, deterministic (bytes in / bytes out).
  • - Memory-safe by construction: the memory-safe parser eliminates the buffer-overflow / use-after-free / OOB vulnerability class of C/C++ image decoders — the #1 attack surface when decoding untrusted imagery.
  • - TJXL_GRAY_LEARNED_TREE=1 / TJXL_HIGH_EFFORT=1: opt in to a maximum-compression path that matches cjxl's slow -e7 size (RGB ~1.03×, AI-mask ~parity) while still encoding several× faster — no API change.
  • - Bit-exact wire: 285 / 285 cross-codec round-trip both directions, at e=1 / e=3 / e=7, on AVX2 and NEON — downstream djxl / Pillow / any libjxl reader consumes TurboJXL output transparently.
  • - Memory-safe: no C toolchain, no libjxl, no cmake dependency on customer build farms or CI. AVX2, NEON, and WASM from one source.

Compatibility

Bit-exact on the wire.

  • - 285 / 285 samples pass the cross-codec round-trip gate in both directions (TurboJXL→djxl and cjxl→TurboJXL), on both AVX2 and NEON.
  • - Bit-exact at every cjxl effort tier tested in the parity gate: e=1 (fast-lossless), e=3 (default), e=7 (high effort).
  • - JPEG XL container format unchanged — downstream djxl / Pillow / any libjxl-based reader consumes TurboJXL output transparently.
  • - Encoder env-toggles (TJXL_HIGH_EFFORT, TJXL_GRAY_LEARNED_TREE, TJXL_PALETTE_AUTO) opt in per workload without an API surface change.
  • - ISAs: AVX2 (x86-64), NEON (ARM64), and WASM (relaxed-simd) — one source, three SIMD backends.

libjxl.
Just faster, safer.

Existing pipelines, existing data, existing tooling. Swap the implementation, keep everything else.

Back to Suite

JPEG XL is an ISO/IEC standard (18181). libjxl, cjxl, and djxl are the reference implementation, published by the JPEG XL Project / Google under a BSD-3-Clause license. References here identify the products and formats being compared; no affiliation, sponsorship, or endorsement is implied. TurboJXL is an independent, clean-room memory-safe implementation that interoperates with the standard JPEG XL bitstream. The live demo runs the unmodified libjxl decoder under its BSD-3-Clause license. Performance comparisons reflect our own measurements under the stated methodology; results vary by workload and hardware.