rusty_jpeg 0.4.4 Ties zune-jpeg on ArtCraft's Photos

ArtCraft's spreadsheet inserts pictures into cells. The picture they timed is a baseline JPEG, 2000 by 1250, about 269 KB, 4:2:0. Their video editor decodes Motion JPEG frames at 1920 by 1080. On 22 October 2026 they had already sent rusty_jpeg 0.4.3 back, because it lost those races to zune-jpeg 0.5.15, and the calls stayed on zune-jpeg. Version 0.4.4 is the release cut for that report. Under rusty_alloc, the allocator those programs ship, the same photo ties or beats zune-jpeg, and the frame ties. The pixels of 0.4.4 match 0.4.3. The pipeline that pins this crate is remade_ffmpeg_rs. The catalog is Remade with Rust. The Vorbis half of the same week is rusty_vorbis on ArtCraft's file.

Trust is a ratio from the same bytes, the two decoders alternating which one runs first. Security is a photo parser with no C library in the process. Incentive is a house JPEG the spreadsheet can keep because it is no longer the slow one. The Electronic Frontier Foundation treats the parser inside a file as a security boundary. The NIST Secure Software Development Framework asks for that boundary in a memory-safe language.

How rusty_jpeg 0.4.3 Lost to zune-jpeg

The number is rusty_jpeg's time divided by zune-jpeg's. Above 1 is slower. The decode-only probe ran in one process, 20 rounds of 20 decodes, pinned, RGB out, the same bytes in both arms. On one core, 0.4.3 took 1.67–1.73× as long on the photo and 1.82–1.96× on one frame. On eight cores those were 1.35–1.39× and 1.50–1.55×. Forcing the decoder onto one thread did not close it: 1.37–1.54× on one core, 1.42–1.57× on eight.

The apps agreed, on their own clocks. Inserting the photo into the spreadsheet was 1.54× on one core and 1.34× on eight. Decoding the Motion JPEG movie was 1.36× on one core and 1.30× on eight. A null arm, the same binary against a copy of itself, sat near 1. Pixels stayed within a few least-significant bits of zune-jpeg, and matched the jpeg-decoder 0.3.2 line this crate was vendored from. It was a speed report. The apps went back to zune-jpeg.

What rusty_jpeg 0.4.4 Changed on the 4:2:0 Path

The common photo is baseline 4:2:0 into RGB. That is the path 0.4.4 spends its change on. Color conversion and chroma upsampling run as wider vector steps. The output pixels of 0.4.4 match 0.4.3 on both of ArtCraft's images, so the speed work did not repaint the picture. The still-image stack is the older page for PNG and JPEG as a family. This page is the October measurement against zune-jpeg, the pure-Rust decoder the spreadsheet was already using.

rusty_jpeg fills the RGB buffer without zeroing it first

A decode that clears the output and then writes every pixel pays for the memory twice. 0.4.4 fills the RGB buffer from uninitialized capacity. The bytes a caller reads are the converted pixels. The zero pass is gone. That sits with the wider color and upsample steps. It is not a new pixel format. Callers still get RGB, the same width and height, the same channel order they had on 0.4.3.

A one-core rusty_jpeg decode does not start a spare worker

The 0.4.3 single-thread switch was a flag the app could set, and that mode still lost to zune-jpeg. 0.4.4 also refuses to start a worker thread when the process can use only one core, because that thread has nowhere to run. Separately, the worker picker had compared width with width, so a wide frame could choose the wrong plan. It now compares width with height. Both of those are scheduling. They do not change the RGB that comes out, which is why the pixel check against 0.4.3 still holds.

zune-jpeg still leads rusty_jpeg on the system heap

Under the system allocator, one core is still slower: 1.13–1.15× on the photo and 1.22–1.24× on the frame. A decode asks for about 3 MB of planes, and the system heap faults those pages in. On four logical cores the photo's default mode flips the other way, 0.94–0.95×, while the frame stays near 1.07–1.14×. Reusable plane buffers would keep that 3 MB from being faulted on every picture. They are not in 0.4.4.

remade_ffmpeg_rs Pins rusty_jpeg 0.4.4

The workspace lockfile takes rusty_jpeg 0.4.4 from crates.io. The JPEG adapter in the media pipeline calls it. That pipeline is what a Disco Party node and FFAI use for media. ArtCraft's report is the week that adapter's decoder caught zune-jpeg on the allocator the apps already chose.

rusty_alloc is the rusty_jpeg tie ArtCraft can ship

ArtCraft's programs set rusty_alloc as the global allocator. On that allocator the photo is 0.96–0.98× on one core, faster on 17 to 19 of 20 rounds, and the single-thread mode is 0.95–0.98×. The frame sits on the line, 0.97–1.05× depending on thread mode, with several rows inside a tie rather than a win. zune-jpeg itself got faster once both arms used rusty_alloc: a median 6.4 ms to 5.4 ms on the photo, one core, about 20 percent. What rusty_alloc changes is that heap. The full insert loop and the full movie decode were timed on 0.4.3. They have not been repeated as whole programs against 0.4.4. The probe is the measurement we have, and it is the one that justifies putting 0.4.4 in front of those calls.

A mata.network page does not open rusty_jpeg

The public site is built ahead of time. A request for a Learn page does not decode a JPEG. The protection against a slow or hostile image parser is which binary decodes when media is the job. That binary is remade_ffmpeg_rs. Why the distributed cloud needs memory-safe Rust is the argument for keeping that job in Rust. A photo in a spreadsheet cell is a different process from a page on this site, and only the spreadsheet process was timed.

ragconverter.com already decodes with rusty_jpeg

ragconverter.com uses rusty_jpeg so a picture can become text for a private corpus without leaving the browser tab. The same crate, since 0.4.0, is the no_std JPEG decoder on the ESP32 camera path: it reads a byte slice and can scale the picture down before the full frame is held. Ship notes for the remade stack go to futureweb.news. The importance of Remade with Rust is the catalog those notes belong to.