33% smaller than brute-force crushed PNG files (using ZopfliPNG),
43% smaller than typical PNG files,
46% smaller than optimized Adam7-interlaced PNG files,
53% smaller than lossless JPEG 2000 compression,
74% smaller than lossless JPEG XR compression.
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.)
Works on any kind of image
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.
More recent formats like WebP and BPG do not solve this problem, since they still have their strengths and weaknesses.
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.
Progressive and lossless
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.
Responsive by design
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.
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 freedom to study how the program works, and adapt it to your needs.
The freedom to redistribute copies.
The freedom to improve the program, and release your improvements to the public, so that the whole community benefits.
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.
Support for embedded ICC color profiles, Exif and XMP metadata
Rudimentary support to compress camera raw files (RGGB)
Encoding and decoding speeds are acceptable, but should be improved
FLIF does not yet support the following features:
Other color spaces (CMYK, YCbCr, …)
Tiles (to store huge images with fast cropped viewing)
Better lossy compression
Native web browser support
Support in popular image tools and viewers
A highly optimized implementation
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.