Hacker News Reader

Comment by kjsthree | Hacker News Reader

How does this compare to FLIF? The responsive features of FLIF seem fantastic. http://flif.info/

In the part where it says "Spot the difference" and everyone says "The BPG one looks worse". That's because BPG, even in "lossless" mode... is lossy. So you're taking a video with H.264 compression artifacts and recompressing it with HEVC artifacts. The quality can only go down.

FLIF on the other hand is lossless, so the image would be truly identical (pixel for pixel). However the filesize will likely be much larger, as MP4 is a very good at lossy compression. What BPG is doing is better performed by HTML5 video formats that already exist due to hardware acceleration support for H.264 and better memory management for video. Also there are patent issues with BPG due to it being based on HEVC.

FLIF is patent free, making it the more likely candidate for mass adoption. It's animation, like APNG is lossless and supports full 24-bit transparency (versus GIF's 8-bit). However the filesize for FLIF is considerably smaller than APNG, even when crushing it with algorithms like Zopfli. Still though, for full frame video, you'll have a better time with MP4, though FLIF will be better quality, it will only be marginal and not likely noticeable in most cases.

What is interesting is the responsive aspect of FLIF. If you encoded an HD video, but only display it on a page at a lower resolution, it will only download the minimum amount of data required to display the image up to that resolution. So it could technically require a lot less bandwidth from a server compared to MP4 if the user doesn't fullscreen the video. But this is more to do with implementation than with formats. YouTube does this same idea, though with a completely different style of execution, in which they only give the the quality for the resolution you are playing it at.

FLIF is encumbered by GPL, so it is unlikely to make its way into digital cameras.

The first official version of FLIF has not been released yet, and currently they are discussing releasing it under Apache 2 or MPL (Mozilla Public License).

1) How does a GPL'ed reference implementation prevent digital cameras from using the format?

2) The reference implementation will most likely change to a more permissive license, cf https://github.com/FLIF-hub/FLIF/issues/192

3) If digital cameras would use FLIF, they would probably need to implement a simplified encoder in hardware, e.g. one that uses a hardcoded (set of) MANIAC tree(s) and only uses a subset of the available encoding options. Otherwise it will be too slow.

In this example .mp4 video, I extracted the frames as 369 invidual PNG files, with a total size of 193MB.

Encoding those 369 PNG files to a LOSSLESS BPG animation (using bpgenc 0.9.6 with options -lossless -a) produces a .bpg file of about 50MB.

Encoding them to APNG (using apngasm 2.7) results in a 57MB animated PNG file.

The corresponding progressive FLIF animation is 20 MB.

Obviously it is not a good idea to losslessly encode lossy images/movies, as a lot of bytes are wasted on encoding compression artifacts.

FLIF only has a lossless mode. For lossless animation, it usually beats GIF, APNG, MNG, WebP and BPG. It is the only responsive animation format afaik.

For lossy movies, actual video codecs are best, since they're designed for that. BPG is essentially HEVC (a great but patent-encumbered video codec) so it should be good at lossy movies -- it will be worse on line-art animations with hard edges like e.g. cartoons, or animations with transparency.

I don't think this is entirely fair. The full encoding of FLIF is lossless, yes, but it has VERY strong progressive decoding.

You could just truncate the file at x% and get lossy encoding that way.

Thanks for the compliment about FLIF's progressive decoding! (FLIF author speaking here)

However, truncated FLIF files will (probably) never achieve the same quality/size ratio as dedicated lossy methods that can produce a completely different file for each quality setting.

So at the moment I still see an important use case for lossy methods. However, in the future, I can imagine that people will start to demand/expect lossless encoding, to avoid generation loss and to get the most out of their display hardware. E.g. higher bit depths are becoming a thing, while the JPEG/WebP color space (YCbCr) is effectively less than 22 bits per pixel (roughly speaking, red and blue are only 7-bit), and chroma subsampling makes this even worse. Also what's the use of ever higher display resolutions if most of those pixels are only displaying compression artifacts or blur? Lossy formats like JPEG/WebP/BPG/JP2/JXR are good at medium-quality, but if you use them at a near-lossless quality setting (e.g. 99 or 100 for JPEG), they often produce bigger files than lossless formats.

Meanwhile, the range of display sizes is getting larger: while in the past, we had a range from say 13" monitors to 21" monitors, now we have a range from 1.5" smart watches to huge 100" smart TVs. I do think that in order to avoid huge amounts of rescaling/transcoding, we need image/video formats that are "responsive by design", like JPEG2000 and FLIF (and progressive JPEG to some extent).

As a fun side project I was thinking of writing a clean room FLIF en/decoder, but I can't seem to find any paper or real explanation of the mechanics. Are those coming, or did I just miss those?

There is a paper draft at https://github.com/FLIF-hub/FLIF-doc, but most of the details still have to be written down (i.e. they're only in the code).

Writing out the detailed spec is going to take some effort.

Good luck, it sounds like a great format! One really nice thing about lossless formats is that they are great for archival purposes since you can easily convert them to whatever format is currently optimal or convenient for end use (if you don't want to use it directly). I shudder at the number of complex video implementations that may need to be supported forever due to quality loss if you convert them.

FLIF is based on context mixing so it's extremely slow but has an extremely high (lossless) compression ratio. It's designed for image archival and not for real-time streaming video. It does have some interlacing techniques for previewing the image in a lower resolution but really it's orders of magnitude slower than other image formats.

The current decode time (on a lower end ARM CPU) is approx 1 megabyte per second. This of course will increase as the format is finalized and better/more optimized decoders are written for it. As well as with CPU speeds increasing. Though even at the current rate it should be fast enough in almost any real world scenario. A 1080p video on youtube is about 260-320 kilobytes per second. So as long as video quality doesn't demand 3-4 times what we are currently getting from HD video online, it should decode faster than it matters. Plus the whole video is available as it downloads in a lower resolution. It just gets clearer the longer it plays. Which is a much better experience than GIF/APNG/BPG/WebP and even MP4 in use as a GIF replacement. Though the MP4 will almost certainly be visually as good of quality at a consistently much smaller filesize due to H.264's fantastic lossy compression.

Wow! This is amazing!

Reply on news.ycombinator.com