FLIF is a novel lossless image format which outperforms PNG, lossless WebP, lossless BPG, lossless JPEG2000, and lossless JPEG XR in terms of compression ratio.
According to the compression experiments we have performed [older results here], FLIF files are on average:
Even if the best image format was picked out of PNG, JPEG 2000, WebP or BPG for a given image corpus, depending on the type of images (photograph, line art, 8 bit or higher bit depth, etc), then FLIF still beats that by 12% on a median corpus (or 19% on average, including 16-bit images which are not supported by WebP and BPG).
The file format has been standardised and versioned. The latest stable version is FLIF16 and is documented here.
Here are some of the key advantages of FLIF:
The results of a compression test similar to the WebP study are shown below. FLIF clearly beats other image compression algorithms. (Note: the graph below is for an early version of FLIF. It has slightly improved since then.)
FLIF does away with knowing what image format performs the best at any given task.
You are supposed to know that PNG works well for line art, but not for photographs. For regular photographs where some quality loss is acceptable, JPEG can be used, but for medical images you may want to use lossless JPEG 2000. And so on. It can be tricky for non-technical end-users.
FLIF works well on any kind of image, so the end-user does not need to try different algorithms and parameters. Here is a selection of different kinds of images and how each image format performs with them. The conclusion? FLIF beats anything else in all categories.
Here is an example to illustrate the point. On photographs, PNG performs poorly while WebP, BPG and JPEG 2000 compress well (see plot on the left). On medical images, PNG and WebP perform relatively poorly (note: it looks like the most recent development version of WebP performs a lot better!) while BPG and JPEG 2000 work well (see middle plot). On geographical maps, BPG and JPEG 2000 perform (extremely) poorly while while PNG and WebP work well (see plot on the right). In each of these three examples, FLIF performs well — even better than any of the others.
FLIF is lossless, but can still be used in low-bandwidth situations, since only the first part of a file is needed for a reasonable preview of the image.
Other lossless formats also support progressive decoding (e.g. PNG with Adam7 interlacing), but FLIF is better at it. Here is a simple demonstration video, which shows an image as it is slowly being downloaded:
Lossy compression is useful when network bandwidth or diskspace are limited, and you still want to get a visually OK image. The disadvantages of lossy compression are obvious: information is lost forever, compression artifacts can be noticeable, and transcoding or editing can cause generation loss. With better compression, the need to go there is lessened.
Here is an example to illustrate the progressive decoding of FLIF, compared to other methods.
A FLIF image can be loaded in different ‘variations’ from the same source file, by loading the file only partially. This makes it a very appropriate file format for responsive web design.
Read more about FLIF and Responsive Web Design
Try the Poly-FLIF interactive demo by hrj!
Unlike some other image formats (e.g. BPG and JPEG 2000), FLIF is completely royalty-free and it is not known to be encumbered by software patents. At least as far as we know. FLIF uses arithmetic coding, just like FFV1 (which inspired FLIF), but as far as we know, all patents related to arithmetic coding are expired. Other than that, we do not think FLIF uses any techniques on which patents are claimed. However, we are not lawyers. There are a stunning number of software patents, some of which are very broad and vague; it is impossible to read them all, let alone guarantee that nobody will ever claim part of FLIF to be covered by some patent. All we know is that we did not knowingly use any technique which is (still) patented, and we did not patent FLIF ourselves either.
The reference implementation of FLIF is Free Software. It is released under the terms of the GNU Lesser General Public License (LGPL), version 3 or any later version. That means you get the “four freedoms”:
The reference FLIF decoder is also available as a shared library, released under the more permissive (non-copyleft) terms of the Apache 2.0 license. Public domain example code is available to illustrate how to use the decoder library.
Moreover, the reference implementation is available free of charge (gratis) under these terms.
FLIF source code
UGUI: FLIF - A GUI for FLIF
Phew - FLIF Viewer for OSX
FLIF currently has the following features:
FLIF does not yet support the following features:
FLIF is based on MANIAC compression. MANIAC (Meta-Adaptive Near-zero Integer Arithmetic Coding) is an algorithm for entropy coding developed by Jon Sneyers and Pieter Wuille. It is a variant of CABAC (context-adaptive binary arithmetic coding), where instead of using a multi-dimensional array of quantized local image information, the contexts are nodes of decision trees which are dynamically learned at encode time. This means a much more image-specific context model can be used, resulting in better compression.
Moreover, FLIF supports a form of progressive interlacing (essentially a generalization/improvement of PNG's Adam7 interlacing) which means that any prefix (e.g. partial download) of a compressed file can be used as a reasonable lossy encoding of the entire image. In contrast to other interlacing image formats (e.g. PNG or GIF), interlaced FLIF encoding takes the interlacing into account in the pixel estimation and in the MANIAC context model. As a result, the overhead of interlacing is small, and in some cases (e.g. photographs) interlaced FLIF files are even smaller than non-interlaced ones.
Many more technical details can be found in the publications section of this website.
FLIF development is currently sponsored by Cloudinary, the image back-end for web and mobile developers. Obviously Cloudinary fully supports the FLIF format, both as an input format and an output format.