QOI-Remix

QOI-Remix is Sunset's incompatible variant of Dominic Szablewski's excellent Quite OK Image Format with the aim of providing a measurable density improvement with a moderate compute penalty.

Compared to PNG, QOI-R is generally...

Much faster, especially on encode. Depending on platform, it's typical to see QOI-R do 25-35x libpng encode throughput and 2-5x libpng decode throughput.
Competitive on size to libpng, though there are exceptions on particularly dictionary-friendly images. QOI-R images range from moderately smaller than PNGs to significantly larger, with an average of very slightly larger. Semi-frequently, QOI is larger than PNG and QOI-R is smaller than PNG.

Compared to QOI, QOI-R is generally...

A little slower (~10-25% lower encode throughput, ~10% lower decode throughput - though with a significant exception on one platform, where QOI-R encode throughput exceeds QOI but QOI-R decode throughput is drastically lower.)
Smaller, though there are exceptions. Many images are effectively the same size between QOI and QOI-R, while on others, QOI-R achieves substantial reductions. Image size comparisons on the QOI benchmark corpus are included in the source tree.

What did QOI-R change?

QOI-Remix incorporates three major changes from QOI.

Changes to the run length encoding that allow for slightly more efficient encoding of long runs, equivalent encoding of short runs, and less efficient encoding of medium runs; this opens up encoding space for other changes
A new dense pixel format, allowing a substantial percentage of RGB pixels to be encoded in three bytes rather than four
A new second-level recent-pixel index, with 1024 entries, that can encode a reference to a recent pixel in two bytes

What is QOI-R for?

I had a couple of days to kill and thought QOI was really cool. That's it. Most of QOI-R was designed and implemented while spending several hours in a waiting room. There's not a grand plan or use case here. It's not intended to replace PNG, and it's not intended to replace QOI - but to provide an alternative on a different part of the lossless image compression Pareto curve. It's very fast, embeddable, fairly portable, and produces dense files.

What does QOI-R include?

The QOI-R distribution includes both QOI and QOI-R support.

qoi.h - the upstream QOI format, unmodified
qoir.h - the new QOI-R code, derived from qoi.h, heavily modified but largely using compatible interfaces
qoirbench - a tool for doing bulk benchmarking of performance and compression for QOI, QOI-R, and libpng (but not STB PNG, unlike upstream qoibench)
qoirconv - a tool for doing file conversions between QOI, QOI-R, and PNG (using STB PNG) in any direction

What is the future of QOI-R?

The QOI-R bitstream format is essentially done. There are a few things I'm working on for QOI and/or QOI-R - KImageFormats support, optimized assembly backends, and some helpful utilities. These will be released over time.

I have ideas for a lossless image format that would be a larger departure from QOI, and will probably end up being named QUAIL. This may inherit concepts from QOI and QOI-R but will be a distinct format with its own magic number, and not a new QOI-R version.

Where's the spec?

I'll upload a proper spec soon. Until then, the code is simple and I welcome questions!

Dependencies

The base qoir.h should be usable with no significant external dependencies except a "normal" system environment (a C99 compiler, 8-bit bytes, some concession to POSIX, etc.)

qoirbench depends on libpng and the presence of stb_image.h (from the "stb" library by nothings, available at https://github.com/nothings/stb). qoirconv depends on stb_image.h and stb_image_write.h, but not libpng.

Platform Support

QOI-R is very new, and has been only tested and validated on a handful of platforms. That being said, it should compile on any system with a more or less sane POSIX environment. qoirbench, in particular, has had some small portability changes to make it less Linux-dependent than upstream QOI.

QOI-R has been tested on:

Linux on x86-64, ARM64, and PPC64LE, with GCC
Linux on IBM Z (notably, a big-endian Linux platform)
HP-UX 11i v3 on Itanium, with slight makefile tweaks to accomodate HP compiler parameters

In the near future, I would like to test it on:

Embedded systems, including QNX (which will almost certainly work without significant changes), LynxOS, and light RTOS's like FreeRTOS and MQX
AIX, somewhat against my better judgment
NT
Mac OS
OpenVMS
OpenVOS
Nonstop

I would welcome an email from anyone that compiles QOI-R on a platform I haven't validated.

Performance Notes

The ratio of QOI-R to QOI performance varies between systems and compilers. I'm not going to publish concrete figures, because benchmarking methodology is a whole art and vendors often get prickly about how it's done, but I will list performance ratios based on megapixels per second, with libpng as the baseline, so that users can use to project performance on their hardware of choice.

These numbers are using QOI's benchmark image set. Usual caveats regarding benchmarks apply. libpng is normalized to 1.0.

x86-64 (Tiger Lake, Linux, gcc 13.1, nonvirtualized)

         Encode    Decode
QOI      38.82     3.23
QOIR     31.89     2.98

ARM64 (Altra, Linux, gcc 8.5.0, virtualized)

         Encode    Decode
QOI      32.83     3.39
QOIR     27.70     2.93

Z (z15 T02, Linux, gcc 9.3.0, virtualized)

         Encode    Decode
QOI      30.17     2.21
QOIR     25.61     1.99

PPC64LE (Power9, Linux, gcc 9.3.0, virtualized)

         Encode    Decode
QOI      33.50     4.65
QOIR     28.06     4.15

Itanium (Itanium 95xx, HP-UX, aCC, nonvirtualized)

         Encode    Decode
QOI      24.65*    3.32
QOIR     28.50*    1.79

This is not a typo. QOI-R encode outperforms QOI encode on this platform. I haven't had an opportunity to do a deep examination of the reason; it's also interesting that QOI-R decode is substantially slower than QOI.