phoboslab

qoi

C2021–2025

phoboslab / qoi

qoi

The “Quite OK Image Format” for fast, lossless image compression

Creative & Media Data & Databases

Explore on GitHub Read Hacker News discussions

17Distinct people

17Mentions

0Explicit recommenders

7.6KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

The “Quite OK Image Format” for fast, lossless image compression

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year17 dated mentions

Observed mentions: 2021-11-24 14:22:16 UTC to 2025-07-28 22:01:14 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	11	3	8
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	3	0	3
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	2	0	2
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	0	0	0
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	1	0	1

What Hacker News says

17 sources

sitkack·Jul 28, 2025

I'd want to know how it compares to https://github.com/phoboslab/qoi One thing to note when designing a new video codec is to carpet bomb around the idea with research projects to stake claim to any possible feature enhancements. Anything can have an improvement patent filed against, no matter the license.

In I designed my own fast game streaming video codec – PyroWave

smcameron·Dec 10, 2023

> I would bet that these days, generating or decoding PNGs is the bottleneck almost nowhere The bulk of my game's startup time is spent decoding PNGs via libpng. There are some alternatives to libpng like fpng[1], or alternate image formats like QOI[2] These both exist because png is slow and/or complicated. [1] https://github.com/richgel999/fpng [2] https://github.com/phoboslab/qoi (discussed here: https://news.ycombinator.com/item?id=29661498)

In CPNG, a backwards compatible fork of PNG

NovemberWhiskey·Mar 3, 2023

Her request is politely-phrased and reasonable. I don't think there's a legal or ethical issue, but respecting the wishes of others when it costs you nothing is just kindness. However, the way that some have seized on it, and then interacted with others in their communities is ... neither polite nor reasonable. e.g. https://github.com/phoboslab/qoi/issues/35

In Ethically Sourced Lena Picture

travisgriggs·Jun 8, 2022

I was kinda sad QOI (https://github.com/phoboslab/qoi) wasn’t included in the comparisons.

In What’s the best lossless image format?

moron4hire·May 1, 2022

Yes. Without a supporting statement, it's ad hominem. But I provided a supporting statement. This is the issue I'm taking about: https://mobile.twitter.com/richgel999/status/146443578680850... Which links to here: https://github.com/phoboslab/qoi/issues/35 It got so bad even John Carmack told him he was out of line: https://twitter.com/ID_AA_Carmack/status/1464639553046728709... Where everyone agrees, yes, the image should be removed. They didn't know about its history. Would he please stop being a gigantic asshole about it. So if that's not blowing things out of proportion, I don't know what is.

In At one company I worked at only one thing mattered: the yearly bonus

mkcg·Apr 2, 2022

I don't know about CUDA, however I've made an AVX2 based encoder a few months ago : https://github.com/phoboslab/qoi/pull/143 I intend to create an AVX2 based decoder but I had absolutely no time to work on side projects in the past three months. You might also want to take a look at this streaming encoder if you want to encode large files with a tiny memory footprint : https://github.com/MKCG/php-qoi/blob/main/src/FFI/lib/qoi.c

In QOI – The Quite OK Image Format

versteegen·Dec 24, 2021

It's because this link (https://github.com/phoboslab/qoi) has been approved by mods for reposting: it appears on the "pool" list [1] [2]. Which is a bit odd because as you point out, a different link [3] for the same project already received lots of attention. [1] https://news.ycombinator.com/pool [2] https://news.ycombinator.com/item?id=26998308 [3] https://news.ycombinator.com/item?id=29625084

In QOI – The “Quite OK Image Format” for fast, lossless image compression

JeanMo·Dec 23, 2021Submission

QOI – The “Quite OK Image Format” for fast, lossless image compression

200 points · Open discussion

Shank·Dec 20, 2021Submission

QOI – The “Quite OK Image Format” for fast, lossless image compression

3 points · Open discussion

phoboslab·Dec 20, 2021

What exactly do you mean with "edge cases"? For what it's worth, the decoder has been fuzzed[1] and the benchmark suite[2] with 2800 images en-/ and decodes without losing any pixels, as checked by qoibench[3]. [1] https://github.com/phoboslab/qoi/blob/master/qoifuzz.c [2] https://qoiformat.org/benchmark/ [3] https://github.com/phoboslab/qoi/blob/master/qoibench.c#L440...

In The QOI File Format Specification

IshKebab·Dec 20, 2021

This is pretty cool. Though... > all data is now encoded as big-endian. Why? If the goal is to be fast and simple then surely little endian would make more sense given that basically all processors are little endian. Big endian just means you need to swap everything twice. Edit: Seems like I'm not the only person that thought this was a super weird choice: https://github.com/phoboslab/qoi/issues/36 The reasoning is: > The file format for QOI will not change anymore.

In The QOI File Format Specification

Animats·Nov 26, 2021

It checks for running out of input but, at line 460, will read three bytes beyond the end of the buffer for suitably constructed input. This is technically wrong, but hard to exploit. Amusingly, if you run out of input too soon, the last pixel is replicated to fill the buffer. So you don't get random memory contents in the output, which would be more exploitable. [1] https://github.com/phoboslab/qoi/blob/master/qoi.h

In QOI: Lossless Image Compression in O(n) Time

ingve·Nov 26, 2021Submission

QOI: “Quite OK Image” format for fast, lossless image compression

2 points · Open discussion

hackerfactor1·Nov 24, 2021

There are a lot of better-than-JPEG and better-than-PNG solutions out there. Speed: If the benchmarks are correct, then this is exceptional, especially considering that the file size is only slightly larger than PNG. I can think of a couple of ways they could reduce the file size by probably around 10%-20% without sacrificing speed, but this is good enough to get attention. The biggest speed loss for PNG comes from zlib. PNG without zlib is very fast -- probably comparable to QOI. If QOI use bz2 or even zlib on top of the current encoding scheme, then it would be slower, but I bet it would also be smaller than PNG. The biggest issue isn't making a better/faster picture format. Rather, the biggest issues are adoption, metadata, and variable color support. Until web browsers and smartphones natively support the format, it's only good for a

Read the rest

proof-of-concept or for niche applications. (Don't get me wrong -- online games could benefit from something like this.) Wide-spread consumer adoption will also need support for metadata. EXIF, IPTC, XMP, ICC Profiles, etc. This is easy enough to add. I hope the author choose something simple, like a tag-length-data. The tag just identifies it as a meta block. The data should begin with a text string and "\n" that defines the type of data, followed by the binary data. The "length" includes the size of the data + string + 1 for "\n". Also, be aware that some metadata is larger than 65535 bytes, so the length should support large data blocks. The algorithm as currently defined only supports 8-bits per channel and 3 or 4 channels (RGB or RGBA). For widespread adoption, it should support: - 8-bit Grayscale (1 byte per pixel) - 16-bit Grayscale (2 bytes per pixel) - 8-bit Grayscale + Alpha (2 byte per pixel) - 16-bit Grayscale + Alpha (4 bytes per pixel) - 8-bit and 16-bit RGB (24 and 48 bytes per pixel) - 8-bit and 16-bit RGBA (32 and 64 bytes per pixel) - 8-bit and 16-bit CMYK (for the printing industry) - 8-bit YUV (for cameras; most also support 16-bit YUV, but it's rarely ever seen) I don't think the algorithm will change for these, but the file format will need a header that defines the color space and color depth. The source code is also problematic. For example, the .h (header) file contains functions. Not function definitions, but actual functions. E.g.: https://github.com/phoboslab/qoi/blob/master/qoi.h All functions (qoi_encode, qoi_decode, etc.) are completely included in this header file. It should be in a .c file (not .h) and compiled into a library (libqoi). Although C does permit you to put functions in header files, it is REALLY REALLY REALLY bad form and strongly discouraged. (This is a really bad programming practice. When I was in school, doing this sort of thing would be an immediate homework failure even if the code works.)

In QOI: Lossless Image Compression in O(n) Time

hn_acc_2·Nov 24, 2021

1) Include it wherever it's used. The convention is to use the preprocessor[1] so it only appears once in the final binary 2) Most developers just want to compile to a single binary. Any developer who for some reason needs separately compiled objects should be able to quickly achieve that from a single-file library [1] https://github.com/phoboslab/qoi/blob/324c2243b2fb35f741a88d...

In QOI: Lossless Image Compression in O(n) Time

Showing the 15 most recent of 17 sources. Enable JavaScript to search and browse every indexed mention.