oximg

High-performance image compression in Rust: a library, a CLI, and a self-hostable HTTP server (PoC). JPEG, PNG, WebP — and AVIF with the avif feature — in and out; sources are format-sniffed by magic bytes and re-encoded in their own format. On imgproxy's official benchmark harness, run on the same AWS instance types as their published results, oximg leads every format cell on both x86-64 and Graviton while resizing in linear light at measurably higher output quality (see Benchmarks).

Features

• HTTP resize service: GET /resize/{w}/{h}/{file} fits the source within w x h (never enlarges) and re-encodes it in its own format. Sources come from a local directory or any HTTP(S) origin (OXIMG_SOURCE_BASE_URL), where decoding overlaps the download. Optional imgproxy-style HMAC URL signing.
• Quality-first processing: resizing happens in linear light on 16-bit samples with Lanczos3, JPEG sources are decoded supersampled (DCT shrink-on-load kept ≥ 1.7x the target), and alpha is premultiplied across the resample — the properties behind the SSIMULACRA2 scores in Benchmarks.
• Performance as architecture, not flags: per-arch row-streaming SIMD resize kernels (AVX2 on x86-64, NEON on aarch64, both verified against an f64 reference), JPEG decode fused with resize+encode on a second thread under low load, request coalescing for concurrent identical URLs, and CPU concurrency pinned to the core count. Peak memory stays at a fraction of imgproxy's under identical load (BENCH.md).
• Tunable profiles: the default maximizes quality per byte (progressive jpegli); one env flip (OXIMG_JPEG_PROGRESSIVE=0) trades ~10% output size for the lowest latency at unchanged pixels. PRESET=fast|small selects mozjpeg profiles instead.
• Self-contained deploys: multi-arch Docker images (linux/amd64 + linux/arm64) on Docker Hub (oximg/oximg) and GHCR (ghcr.io/oximg/oximg); a single static-leaning binary otherwise.

Supported formats

Sources are identified by magic bytes (extensions are never trusted) and re-encoded in their own format:

Cross-format output (JPEG in → WebP/AVIF out, Accept negotiation) is not implemented yet — see Not yet implemented.

Pipeline

source bytes (local file or HTTP origin)
  → format sniff → decode
      JPEG: mozjpeg streaming decode, DCT shrink-on-load (kept ≥ 1.7x target size)
      PNG:  png crate (palette/gray/16-bit normalized to RGB(A)8)
      WebP: libwebp
      AVIF: dav1d (8/10/12-bit, all subsamplings, alpha, bilinear chroma upsampling)
  → linear-light resize: sRGB u8 → linear u16 → Lanczos3 → sRGB u8
      (alpha is premultiplied before resampling, unpremultiplied after;
       JPEG rows stream through in-tree ring-scheduled f32 row kernels —
       AVX2 on x86-64, NEON on aarch64, both verified against an f64
       reference — optionally fused with the decode on a second thread;
       other formats resize full-frame: pic-scale on x86-64, the same
       in-tree kernel on aarch64)
  → encode in the source format
      JPEG: jpegli, progressive (PRESET=fast / PRESET=small select mozjpeg profiles)
      PNG:  png crate | WebP: libwebp | AVIF: SVT-AV1 (10-bit 4:2:0, tune=ssim)

Concurrent identical requests are coalesced and share one result. CPU concurrency is pinned to the core count with a semaphore; the HTTP layer (axum/tokio) only does queueing and IO.

Benchmarks

imgproxy's official harness (DIV2K corpus over nginx, fit into 512x512, k6, all defaults) on the AWS instance types behind imgproxy's published numbers — req/s, higher is better, p95 in parentheses:

At the same time, output quality is higher, not traded away: end-to-end JPEG at the same q80 scores +6 to +18 SSIMULACRA2 over imgproxy (77.5 vs 71.2 on the Kodak corpus, the gap widening with source size — and imgproxy at q90 with twice the bytes still scores lower), pure resize quality (lossless PNG path) scores 97.6 vs 81.9, and the AVIF default produces smaller files than imgproxy's default at +6.7 SSIMULACRA2.

• BENCH.md — full methodology and tables: official harness (local and AWS), sustained-load and memory measurements, presets.
• bench/quality/QUALITY.md — output quality (SSIMULACRA2) at matched settings vs imgproxy and sharp.

Usage

Docker (recommended — multi-arch linux/amd64 + linux/arm64, AVIF included; both registries rebuild on every main push):

docker run -p 8081:8081 -v $PWD/images:/images:ro ghcr.io/oximg/oximg:latest
# or: docker.io/oximg/oximg:latest
curl "localhost:8081/resize/500/500/photo.jpg" -o out.jpg

Homebrew (builds v0.2.0 from source; JPEG/PNG/WebP, no AVIF):

brew install oximg/tap/oximg

Cargo (crates.io, v0.2.0; add --features avif if SVT-AV1 >= 4.1 and dav1d are installed and visible to pkg-config):

cargo install oximg

Note the release channels lag main: crates.io and the brew formula ship the last tagged release, while the Docker images rebuild on every main push. The npm package @oximg/oximg is a name reservation that points here.

From source:

cargo build --release            # JPEG, PNG, WebP
cargo build --release --features avif   # + AVIF (needs SVT-AV1 >= 4.1, dav1d)
IMAGES_DIR=./images PORT=8081 QUALITY=80 ./target/release/oximg

The Docker build needs no system dependencies — it compiles a pinned post-4.1 SVT-AV1 revision that carries the aarch64 kernels for the still-image path:

docker build -t oximg .

URL signing (optional): set OXIMG_KEY and OXIMG_SALT (hex) to require imgproxy-style signed URLs — /{base64url(HMAC-SHA256(key, salt || path))}/resize/{w}/{h}/{file}.

Environment variables: PORT (8081), IMAGES_DIR (./images), OXIMG_SOURCE_BASE_URL (fetch sources from <base>/<file> over HTTP instead of the local filesystem; streaming decode overlaps the download), OXIMG_MAX_SOURCE_BYTES (64MiB), QUALITY (JPEG quality, 80), OXIMG_WEBP_QUALITY (75), OXIMG_AVIF_QUALITY (55), OXIMG_AVIF_ALPHA_QUALITY (same as color), PRESET (jpegli default; fast = mozjpeg baseline profile, small = mozjpeg trellis+progressive), OXIMG_RESIZE=srgb (resize in sRGB space instead of linear light), OXIMG_RESIZE_BACKEND=fir (use the portable fast_image_resize convolution instead of the platform kernel), OXIMG_AVIF_DECODE_THREADS (dav1d workers; defaults to 2 on x86-64 where SMT absorbs the second thread and 1 on SMT-less aarch64), OXIMG_DCT_MARGIN (1.7), OXIMG_PAR (resize threads, 1), OXIMG_OVERLAP (JPEG requests fuse decode with resize+encode on a second thread, cutting single-request latency ~20%; the default auto fuses while 2 x active requests <= visible CPUs and falls back to one core per request under contention. Serial and fused stream through the same SIMD kernel, so a URL's bytes are identical either way; 1 forces fusing, 0 disables it), OXIMG_JPEG_PROGRESSIVE (0 selects baseline jpegli: a few percent larger JPEG output — still at or below libjpeg-turbo size for the same input, at higher quality — in exchange for moving jpegli's entropy pass off the latency tail: combined with OXIMG_OVERLAP this is the speed profile, ~-13% single-request latency and ~+9% saturated throughput over the default).

Not yet implemented (out of PoC scope)

• Cross-format output and content negotiation (JXL / Accept-driven)
• Animated AVIF sources
• EXIF orientation / ICC profile handling
• Private S3 sources (public/presigned HTTP origins work), caching
• Production-grade load testing

Status

Experimental PoC — APIs and the HTTP interface will change without notice. The @oximg npm package is a name reservation.

License

Apache-2.0.

The compiled binary statically links third-party code (jpegli/libjxl — BSD-3-Clause, Highway — Apache-2.0, mozjpeg/libjpeg-turbo — IJG). Their license texts and required notices are bundled in THIRD-PARTY-LICENSES.md, generated with cargo about. Dependency licensing is gated in CI by cargo deny (deny.toml).