If QOI is interesting because of speed, you might take a look at fpng, a recent/actively developed png reader/writer that is achieving comparable speed/compression to QOI, while staying png compliant.<p><a href="https://github.com/richgel999/fpng" rel="nofollow">https://github.com/richgel999/fpng</a><p>Disclaimer: have not actively tried either.
A couple previous interesting discussions from this past month:<p>- "The QOI File Format Specification" 214 points | 3 days ago | 54 comments: <a href="https://news.ycombinator.com/item?id=29625084" rel="nofollow">https://news.ycombinator.com/item?id=29625084</a><p>- "QOI: Lossless Image Compression in O(n) Time" 1057 points | 29 days ago | 293 comments: <a href="https://news.ycombinator.com/item?id=29328750" rel="nofollow">https://news.ycombinator.com/item?id=29328750</a>
Since we are rehashing this for the 3rd (4th?) time, I'll repeat mine (and apparently many others) key critique: there is no thought at all to enabling parallel decoding, be it, thread-parallel or SIMD (or both). That makes it very much a past millennium style format that will age very poorly.<p>At the very least, break it into chunks and add an offset directory header. I'm sure one could do something much better, but it's a start.<p>EDIT: typo
Didn't HN disallow recent reposts? This (or its spec) was already posted 3 days ago (twice) and then 2 days ago...<p><a href="https://news.ycombinator.com/item?id=29625084" rel="nofollow">https://news.ycombinator.com/item?id=29625084</a><p><a href="https://news.ycombinator.com/item?id=29631717" rel="nofollow">https://news.ycombinator.com/item?id=29631717</a><p><a href="https://news.ycombinator.com/item?id=29643370" rel="nofollow">https://news.ycombinator.com/item?id=29643370</a>
I think QOI inspired the creation of <a href="https://github.com/richgel999/fpng" rel="nofollow">https://github.com/richgel999/fpng</a> which creates standard PNGs and compares itself directly to QOI.
Don't expect too much of QOI.<p>I wanted a simple format that allows you to load/save images quickly, without dealing with the complexity of JPEG or PNG. Even BMP, TIFF and other "legacy" formats are way more complicated to handle when you start looking into it. So that's what QOI aims to replace.<p>There's a lot of research for a successor format ongoing. Block based encoding, conversion to YUV, more OP-types etc. have all shown improved numbers. Better support for metadata, different bit-depths and allowing restarts (multithreading) is also high on the list of things to implement.<p>But QOI will stay as it is. It's the lowest of all hanging fruits that's not rotten on the ground.
I just implemented this format in my game engine and the performances are crazy: images loading is 3.2 times faster (compared to png) and 40 times faster to generate game screenshot!
Is there any open source audio compression format like that? Lossless and very fast. I haven't found any yet.<p>EDIT: I'm thinking about a format that would be suitable as a replacement for uncompressed WAV files in DAWs. Rendered tracks often have large sections of silence and uncompressed WAVs have always seemed wasteful to me.
It is nice but pity it does not have a "turn right" opcode: start going left, on the turn opcode, continue decoding pixels after turning 90 degrees to the right, until you hit a previously decoded pixel or the wall of the bounding box defined after the first two turns, in which case you turn automatically. The file ends when there's nowhere to turn.<p>This would eliminate the need for a header (bloat!) as the end of file is clearly defined, the size is defined after decoding the top and right line (second turn), and it's not so sensitive to orientation (a pathological image can compress very differently in portrait vs landscape in line oriented formats). Color profile can be specified in the spec.<p>Also allows skipping altogether some image-wide bands or columns that are of the background color (defined by the first pixel) as you do not need to walk over all the pixels.
Seems like they benchmarked it against libpng which shows anywhere from 3-5x faster decompression and 30-50x compression. That's pretty impressive and even though libpng isn't the most performant of the png libraries, it's by far the most common.<p>I think the rust png library is ~4x faster than libpng which could erase the decompression advantage but that 50x faster compression speed is extremely impressive.<p>Can anybody tell if there's any significant feature differentials that might explain the difference (color space, pixel formats, .. etc)?
I would love to have something to compress the raw files from my camera. They're huge, I have to keep a ton of them, and I also need to transmit them over internet for my backup.<p>I tried a few standard compression format, with very little luck.<p>Canon has devised a very smart (slightly lossy) compression format for newer cameras, but there's no converter that I know of for my old camera files.<p>So, unless I shell out large amounts of money for a new camera, I'm stuck sending twice the data over the internet. Talk about pollution...
At a previous job was looking at different binary parsing methods. This project looks quite interesting having binary format descriptions in YAML that then can be generated into your language of choice.<p><a href="https://formats.kaitai.io/png/" rel="nofollow">https://formats.kaitai.io/png/</a>