I've been contemplating image compression off and on for years, without doing anything really practical about it, and agree entirely with his comments about existing methods. I'm fed up of seeing jpeg compression artefacts on images; I shall have to play with this and see what happens.

I'm all in favour of simple file formats even at the cost of lower compression ratios... have one of these on me -->

If as MacroRodent mentions below it's an 8-bit spec then you'll see colour artifacts due to compression?

You'd likely see quantising noise where a ten-or-more bit per colour channel is reduced to eight-bit RGB(A), but as it looks like it only accepts eight bit input depths then you'd need to preprocess higher bit depth images before compression, which would give you the option to choose the distortion of your choice: bit slicing, dither, smearing, whatever.

On the other hand, it doesn't look too complex to increase the pixel depth to 16 bits instead of 8, with a cost of an extra bit in the header to indicate depth, and a compressed image potentially twice the size... as always, the more depth in the image, the less chance of two identical adjacent bits. Perhaps you'd need a bigger indexed map?

(just thinking out loud here).

Amen: I frickin' hate JPEG artefacts.* People need to be taught about this stuff: never use JPEG for graphs, text, or anything with hard lines ( especially company logos on websites... you spent all that money paying the graphic designer/ad agency/consultant, but then went and turned it into a 5kB JPEG? Seriously.). In these cases, go for PNG or similar (TIFF if you need precise colour management, SVG if you can). And reserve GIF for cats.

*Although I have to say, I hate WebP artefacts too, but in a different way: excessive compression with WebP can really make photos look weird (see, for example, most of the images on The Guardian). Just because something is apparently good quality on some metric or other, that doesn't mean it actually looks good.

And reserve GIF for cats.

My Cat Overlord has expressed his displeasure at that statement --> icon

"We are not amused".

Kwah? Koi? Queue oh eye?

It's gif/jif all over again!

I vote for "kawaii"

So do I, their Pianos really are quite lovely to play, although I'm not sure how that suits them for government. Err...

Surely like the French quoi, what or why?

Following French for anything related to pronunciation is sure to lead to trouble...

Beware of geeks bearing GIFs.

What's a "jeek"?

Stop carping about the pronunciation. It's clearly "koi"...

A koi fish would also make a good logo.

I'd go for "coo-ee" myself.

Of course, it's an alternative to .png or .bmp. The article doesn't say, but I assume it's an RGB format rather than CMYK (or L*AB), and it might even be HDR. The world seems to be happy enough with alphabet-soup-style names so I don't think that it would be held back even if everyone settles on "queue-oh-eye".

I'd go for the (Ubuntu-friendly) Zulu "q", an [1]alveolar click .

[1] https://youtu.be/WHHGOYu6Fl0?t=125

koi would be fine. Maybe it can get a metadata extension called carp

Qoi Qarp :)

Quoif surely?

I've just read his [1]blog post where he describes the image format and it is *very* simple. (So simple even I can understand it!)

Somestimes, simple is best.

[1] https://phoboslab.org/log/2021/11/qoi-fast-lossless-image-compression

I've dabbled with compression over the years and for the most part it's all quite simple. LZW is a bit mind bending in the way it regenerates the dictionary as it decompresses though and I vaguely recall there's one that uses floating point numbers in a really odd way.

My favourite has always been Huffman because that's the first I ever played with although I also have a soft spot for NTFS compression both the way it handles the bit stream (speed over efficiency) and the way it encodes the cluster allocation.

I havent'. Is it middle-out compression?

I didn't get the joke here: 3x Rust, C with a diacritic?

It's C with the Hungarian notation....

I wonder will someone port it to Rust, though?

According to the docs on Github "Ć is a programming language which can be translated automatically to C, C++, C#, Java, JavaScript, Python, Swift, TypeScript and OpenCL C."

A new one on me, but then I'm very old....

300 lines of C.

So there are still people who can write efficient code that doesn't use up 150MB of RAM just to load.

Count my gast flabbered.

How long are the lines though......?

Would that be the US sense of "quite" or the UK one?

Glanced at the spec. It looks like each colour component is 8-bits only. I think in this day and age there should be an option for a greater colour depth. I can understand he wanted to keep this simple, but sticking to 8 bits prevents using it in some applications. For example, a very simple format like this would be perfect for long-term archiving (no problem including the format spec and decoder source with each volume of images!), but there could really use a greater bit depth.

If that's 8 bits in all, then - congratulations, he's reinvented GIF.

If it's 8 bits per channel, that's 24 bits of actual colour depth, which is respectable IMO.

As someone whose colour vision is rather skewiff, I don't think I can really tell the difference between 16-bit and 24-bit colour. I actually question whether normies can tell the difference between 24-bit and 32-bit colour too,* but then I guess something something dynamic range alpha channel etc.

*10 million colours [1]is apparently oft quoted , so I guess 16.7 million should be enough?

[1] https://doi.org/10.1002/(SICI)1520-6378(199802)23:1%3C52::AID-COL8%3E3.0.CO;2-2

JPEG too is still stuck at 8 bits - but you're right, most images today have a far larger gamut than 24 bits allow.

Anyway this should be tested with a large sample of images - the one in its site is a computer-generated one, for example, and that has a different pixel distribution than a photo, where there could far more subtler changes among pixels.

Moreover today file formats and image compression algorithms are two separate entities. Many image file formats are actually containers that beyond the image data themselves (and sometimes more than one) need to host other data like image metadata, color profiles, etc.

More than 8-bits per channel is really only useful for intermediate formats used during editing to prevent rounding errors accumulating noticeably. It's not very useful for normal colour output. Greyscale, on the other hand, needs more. The encoding given seems like it would be easy to add 24bit greyscale, which is overkill, by using 11111100 and 111111011 (for +alpha) as 8bit flags.

We could always create new versions able to use 10, 12, 16, 17 bits...

--> https://xkcd.com/927/

Expected it to be QUIF

The C code is readable and readily understandable in a single pass.

But what is it's mime type, I'm hoping for image/ok

PNG is widely used, and mobile devices with battery life concerns are an extremely common way to get online these days. Something that lightens the burden when processing images is welcome.

Very nice work, I've been having a gander at the benchmarks.

So you're saying it'd be something to write home about?