Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

41–50 of 105 posts

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

#41

Post by phonon »

wombatmobile wrote: post #31
zigzag312 wrote: post #3

Is there any open source audio compression format like that? Lossless and very fast. I haven't found any yet. 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.

I'd also like to know what's the best (or any) lossless audio compression process/tools. My application is to send audio (podcast recordings) to a remote audio engineer friend who will do the post processing, then round trip it to me to complete the editing. Wav is so big it makes a 1 hr podcast a difficult proposition. MP3 is unsuitable because compression introduces too many artefacts the quality suffers unacceptab…

1 hour of CD quality mono FLAC encoded is about 100-150 MB. Is that small enough?

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

#42

Post by meltedcapacitor »

FullyFunctional wrote: post #30

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. At the very least, break it into chunks and add an offset directory header. I'm sure one could do something much better, but…

A thread can scan the opcodes only to find cut-off points and distribute actual decoding to other cores. Surely you can do that with some simd magic, as well as the decoding threads, without needing to encode properties of today's simd in the encoding.

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

#43

Post by meltedcapacitor »

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.

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.

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.

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

#44

Post by throwamon »

Didn't HN disallow recent reposts? This (or its spec) was already posted 3 days ago (twice) and then 2 days ago...

https://news.ycombinator.com/item?id=29625084

https://news.ycombinator.com/item?id=29631717

https://news.ycombinator.com/item?id=29643370

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

#45

Post by midjji »

FullyFunctional wrote: post #30

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. At the very least, break it into chunks and add an offset directory header. I'm sure one could do something much better, but…

A surprisingly good image format is to use a per line, or block, ar encoder, then compress the result with gzip on a low setting. It parallelizes very nicely, and beats png for encode, decode, and is trivial to implement.

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

#46

Post by FullyFunctional »

nynx wrote: post #37
FullyFunctional wrote: post #35

Earlier quoted context omitted.

Good question. The answer is all the poor souls that N years later find themselves stuck with a data in a legacy format that they have to struggle to decode faster. Of all the artifacts in our industry, few things live longer than formats. Eg. we are still unpacking tar files (Tape ARchieve), transmitted over IPv4, decoded by machines running x86 processors (and others, sure). All of these formats couldn't possible a…

Unrelated to the rest of your comment, but risc-v does not have variable-length instructions. It has compressed instructions, but they're designed in such a way to be easily and efficiently integrated into the decoder for normal instructions, which are all 32 bits.

My day job for 6+ years is implementing high perf RISC-V cores and my name is in many of the RISC-V specs.

Variable length ISAs are characterized by not being able to tell the beginning of an instruction without knowing the entrypoint. This applies to RISC-V with compressed instructions. Finding the boundaries is akin to a prefix scan and has a cost roughly linear in the scan length, but IMO the biggest loss is that you can’t begin predecode at I$ fill time.

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

#47

Post by phoboslab »

Don't expect too much of QOI.

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.

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.

But QOI will stay as it is. It's the lowest of all hanging fruits that's not rotten on the ground.

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

#48

Post by adgjlsfhk1 »

meltedcapacitor wrote: post #43

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. This would eliminate the need for a header (bloat!) as the end of fi…

Writing an encoder for that sounds like a nightmare though. Also the speed would suck since you would have unpredictable memory accesses.

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

#49

Post by PostThisTooFast »

phoboslab wrote: post #47

Don't expect too much of QOI. 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. There's a lot of research for a successor format ongoing. Block based encoding, conversion to YUV, more OP-types etc. have…

What are we to make of that warning? What shortcomings do you think people will find?

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

#50

Post by PostThisTooFast »

throwamon wrote: post #44

Didn't HN disallow recent reposts? This (or its spec) was already posted 3 days ago (twice) and then 2 days ago... https://news.ycombinator.com/item?id=29625084 https://news.ycombinator.com/item?id=29631717 https://news.ycombinator.com/item?id=29643370

No post body was provided.
Post reply on HN