Great, thanks. It seems there is no technical description available anywhere beyond what you quoted. They haven't written it up, and I couldn't even find comments in the source providing details. That's too bad, but he (I assume that's Jon Sneyers) does say he hopes to write it up later.

Also, comments in that thread on speed [1]:

     In terms of encode/decode speed: both are slow and not very optimized
     at the moment (no assembler code etc, just C++ code). A median file
     took 3 seconds to encode (1 second for a p25 file, 6 seconds for a p75
     file), which is slower than most other algorithms: WebP took slightly
     less than a second for a median file (0.5s for p25, 2s for p75), PNG
     and JPEG2000 took about half a second. It's not that bad though: BPG
     took 9 seconds on a median file (2.5s for p25, 25s for p75), and
     brute-force pngcrushing took something like 15 seconds on a median
     file (6s for p25, over 30s for p75), so at least it's already better
     than that.

     Decode speed to restore the full lossless image and write it as a png
     is not so good: about 0.75s for a median file, 0.25s for a p25 file,
     1.5s for a p75 file. That's roughly 3 to 5 times slower than the other
     algorithms. However, decoding a partial (lossy) file is much faster
     than decoding everything, so in a progressive decoding scenario, the
     difference would not be huge.

[1]: https://boards.openpandora.org/topic/18485-free-lossless-ima...

awesome, thanks for the info! if flif does ultimately consume more CPU resources then that is a trade off I'm perfectly happy to make, I'd rather burn CPU than my heinously bandwidth capped internet.

Here in Israel, bandwidth cap is big for a cheap price - I'm paying around 13USD/month for a package including unlimited voice calls, unlimited SMS and a 3GBs data plan.

What interests me most is battery life - is more CPU and less radio power better?

I hope the author can come back to tell us whether he did comparisons with different speed presets for BPG; it ranges from insanely fast to insanely slow, and that's probably just the default.

I only tried bpgenc with the default speed presets.

It's a bit premature to discuss compression/decompression speed, because this is just a prototype implementation and there are probably many ways to improve the speed. Premature optimization is rarely a good idea.

I posted the news of this new file format weeks ago on HN, no one picked it up :P

What makes it to, and stays on, the front page of HN has a large element of randomness.

Did you remember to put "Free" on the title?

Implicitly yes: "Preview of FLIF, New Lossless Image Format"

So, no.

The power of free. Some good books by Dan Ariely on the topic.