-- Leo's gemini proxy
-- Connecting to arcanesciences.com:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini
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.
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
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.
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
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.
I'll upload a proper spec soon. Until then, the code is simple and I welcome questions!
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.
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.
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.
Encode Decode QOI 38.82 3.23 QOIR 31.89 2.98
Encode Decode QOI 32.83 3.39 QOIR 27.70 2.93
Encode Decode QOI 30.17 2.21 QOIR 25.61 1.99
Encode Decode QOI 33.50 4.65 QOIR 28.06 4.15
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.
-- Response ended
-- Page fetched on Mon May 20 21:18:38 2024