4 ms·
This is really interesting! There seems to be some additional technical information here: https://boards.openpandora.org/topic/18485-free-lossless-image-format
by lt 11y ago
This is really interesting! There seems to be some additional technical information here:
https://boards.openpandora.org/topic/18485-free-lossless-image-format-flif/ 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".
- versteegen 11y agoGreat, 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-image-format-flif/?page=2#comment-399001 https://boards.openpandora.org/topic/18485-free-lossless-ima...
- GhotiFish 11y agoawesome, 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.
- omribahumi 11y agoHere 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?
- silverbacknet 11y agoI 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.
- jonsneyers 11y agoI 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.
- ekianjo 11y agoI posted the news of this new file format weeks ago on HN, no one picked it up :P