Hacker News Reader

Comment by lt | Hacker News Reader

This is really interesting! There seems to be some additional technical information here:

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

  - for interlacing it uses a generalization of PNG's Adam7; unlike PNG, the geometry of the 2D interlacing is exploited heavily to get better pixel estimation, which means the overhead of interlacing is small (vs simple scanline encoding, which has the benefit of locality so usually compresses better)

  - the colorspace is a lossless simplified variant of YIQ, alpha and Y channel are encoded first, chroma channels later

  - the real innovation is in the way the contexts are defined for the arithmetic coding: during encoding, a decision tree is constructed (a description of which is encoded in the compressed stream) which is a way to dynamically adapt the CABAC contexts to the specific encoded image. We have called this method "MANIAC", which is a backronym for "Meta-Adaptive Near-zero Integer Arithmetic Coding".

View on HN

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

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.

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

Reply on news.ycombinator.com