Every public repository, in one list of topics: the map at the end of the READMEs, plus the repositories it does not list yet. Pick a topic, then a project, for what it is, how it is used and how it is tested.
The river above moves the date. Follow the implementation and the work that verifies it.
Following the river: —
Drag to roam, pinch or scroll to zoom. Select any tile to open its neighbourhood — contents, references, and what references it back.
Each crate stands on the crates it depends on (runtime dependencies on our own crates), so foundations sit on the ground and codecs, pipelines and products rise on top; a line joins each crate to the one it stands on · block height ∝ log production lines · bands: family / tests / docs · cap = published on crates.io · translucent = no dated origin · outlined platform = hard fork
Current inventory snapshots · manifest references are name matches across the catalogue, not a resolved dependency graph
Compression comparisons belong to a specific corpus, metric, encoder revision, and set of conditions.
The measured frontiers that stood here predate this autumn's encoder work, so they no longer describe the codecs. They come back when the sweeps rerun on the current encoders, with the corpus, metric and encoder commit of every curve stated beside it.
Why frontier AI models can be trusted to help write codecs that read untrusted bytes.
Image codecs take bytes from strangers and turn them into pixels, usually on a server that also holds other people's data. A bug in a decoder is a security hole. All of this work is shaped by that fact, and it is also the reason we can let frontier AI models write so much of the code.
Our crates compile with #![forbid(unsafe_code)], so the compiler rules out out-of-bounds writes, use-after-free and data races. Nobody has to take a reviewer's word for it, human or AI. SIMD goes through two small primitive crates, archmage and magetypes, that wrap the intrinsics once; a few older crates still carry unsafe code, and we treat it as debt.
Decoders and encoders take resource limits (dimensions, pixel counts, memory) and fail cleanly instead of taking the process down. Long jobs accept cooperative cancellation, so a server can stop one that runs too long. We also predict CPU cost before doing the work, so a pipeline can refuse or reroute an expensive request up front.
Our domain is bytes and configuration in, bytes out, which makes it unusually testable. When a C reference implementation exists, we test against it bit for bit: zenav1-aom is checked module by module against libaom, and zenjpegai reproduces the JPEG AI reference encoder byte for byte on 25 of 32 reference encodes. Where pixels are allowed to differ, psychovisual metrics tell us whether a person would see it.
Every product is fuzzed continually, on every platform we ship. Crashes become minimized regression files that every later build has to pass.
Testing at this depth takes data: millions of test files, and 4 to 6 TB of data churned on an average day. That is why we run servers at home and in the cloud. Creative testing (new oracles, differential checks against other decoders, synthetic stress images) is most of the work, more than writing the codecs themselves.
AI agents work on six dedicated development machines with different CPUs and operating systems, so the fast paths are built and tested for macOS, Windows, Linux and WebAssembly, on x86-64 and ARM, instead of on whatever one laptop happens to have.
Bit-exact tests say whether the bytes match; they can't say whether an image looks better. For that we built zensim, our perceptual metric, which we consider the front of the image-quality-assessment field. To get there we ported 141 image-quality metrics to Rust (what each costs to run is on metric-brief.imazen.org), gathered over a terabyte of compressed IQA datasets, and scored millions of image encodes, including synthetic training data, so the metric isn't overfitted to one benchmark. A metric we trust does two jobs: it tells us when a codec change is a real breakthrough, and it steers the encoders' own decisions from the inside.
Provable memory and concurrency safety, hard resource limits and exhaustive testing are what let us use frontier AI models here. A model proposes a change; the compiler rules out whole classes of bugs, and the bit-exact tests, fuzzers and metrics catch most of the rest before anything ships. That is how a small team is building what we intend to be the best collection of codecs and imaging software in the world.
ImageMagick has 913 published vulnerabilities (OpenCVE, checked October 28, 2026). We don't think it belongs on servers that process images from the internet. This toolset is built to replace it there: memory-safe, far faster, with better compression, and generally more capable. It covers most of what people reach for ffmpeg or libvips to do as well.
Access to the models' cybersecurity capabilities would make me faster. Codec work is parsing hostile input, so even safe-Rust codec work trips the models' security filters often. The same access would let me help other projects in the field improve: I've contributed security-relevant fixes to most of the codecs that ship with Google Chrome.
Owner's account, 2026-10-28. Figures in this chapter are the owner's statements unless marked as measured; the measured ones link to their source on this page.
Rented GPUs and servers from their billing records (cost left out), the home fleet's measured capacity, and what the AI services cost, from the owner's books.
This page regenerates from a deterministic inventory. Each collected fact keeps its source; interpretations keep their rationale and revision history. Unknown quantities stay unknown.
Python is counted as test code. Rust test-only items, including inline cfg(test) modules, are classified separately. LOC is a stock measure; additions and removals describe activity. Commits, test cases, test executions, sessions, and prompts are distinct counts. Only collected sources contribute. Third-party and generated code are accounted for separately.