FLIF — Free Lossless Image Format — is a promising innovation in image compression that promises to provide efficiency and flexibility in ways improve upon the current standards. That is, at least, what FLIF co-creator Jon Sneyers hopes. Even though, according to experiments, FLIF beats existing standards of compression by 14% to 74%, there are still a lot of barriers in terms of adoption and support. The Practical Developer reached out to Jon to find out more about his hopes for the image compression format and what barriers and opportunities exist in adopting it.
Jon, why did you create FLIF?
I created FLIF mostly because I don't like the current situation: while there are many different image formats, some of them quite nice, there is no 'universal' image format that you can 'safely' use and it will 'just work', always. JPEG (and its more modern variants JPEG 2000, JPEG XR) is nice for photographs, but use it on line art and you'll get bad artifacts and poor compression. While JPEG is universally supported, the lack of support for transparency and the inevitable generation loss are problematic. PNG is a nice format, but not very suitable for photographs. WebP are basically two formats with one extension; you can consider lossy WebP as an improvement over JPEG, and lossless WebP as an improvement over PNG, but it's still not really a universal image format, and it has some limitations of its own: only 8-bit color depth, no progressive decoding. Then there is BPG, which is better than JPEG in all respects, but patent-encumbered and not very good at lossless encoding and non-photographic images.
So what I would like to have is an image format that 'just works', in the sense that you can give it any kind of image, and it will compress it as well as any other format, or better. I don't think it should be left to image producers (graphic designers, casual users of image editors, webmasters, photographers, ...) to learn about the technical details of all the image formats out there and their encoding options and optimization tools, and pick the best format for each kind of image. Not only does that leave too much margin for user mistakes, in some circumstances, you want to automate the decision, e.g. because you have a website like facebook or twitter where images are uploaded by users and the website has to rescale and transcode the images automatically. But it's not easy to automate such a decision.
I think FLIF has the potential to become such a 'universal image format' that 'just works', so future image editors will not need a complicated "Save as" or "Export" dialog box anymore: just save as FLIF, and it's all good. At least that's my dream 😀
What are the most practical applications for FLIF at this time for developers?
The format is currently still experimental, which means that bitstream-breaking changes can still happen so a FLIF file encoded with today's version of FLIF will probably not decode correctly with next month's version of FLIF. So it's a bit early to use FLIF as a format to distribute images, unless you also include the suitable version of the FLIF decoder. One domain where this can easily be done, is games. FLIF seems to be very good at compressing game graphics, for example animated sprites with transparency. Also, some games contain graphics at two or more different resolutions (e.g. standard and HD), and using FLIF, they could just store the highest resolution, loading the files partially to get the lower resolution versions. The FLIF decoder is Apache 2.0 licensed, so it can easily be integrated in a game project.
I'm currently working on a lossy encoder for FLIF: the format itself is lossless, but you can still modify the original image so that it compresses better, much like pngquant or TruePNG do for the PNG format, or the near_lossless option in recent WebP versions. The nice thing about this approach is that you get the advantages of lossy compression (much smaller files that are visually still OK) but fewer disadvantages: in particular, the problem of generation loss does not apply. Formats that are inherently lossy, like JPEG, behave like a photocopier: if you make a copy of a copy of a copy, it will accumulate artifacts. Lossless formats like FLIF don't have that problem (even if you use them in a lossy way). The interesting thing about lossy FLIF as opposed to lossy PNG or near-lossless WebP, is that it can actually compete with JPEG in terms of compression ratio for a given visual quality, even for photographic material. For non-photographic material, even lossless FLIF often beats high-quality JPEG in terms of compression ratio.
Photograph saved 10 times as JPEG
Photograph saved 10,000 times as JPEG
Photograph encoded 10,000 times as lossy FLIF
Should users of FLIF be concerned about instability of the format and what can they do to ensure early adoption does not hurt them?
Yes, users should be aware of the fact FLIF is still experimental, so if you use it for archiving, you better also keep that exact version of FLIF around to decode the images. Since it is a lossless format, you don't really risk much by converting your PNG images to FLIF: you can always just decode them back to PNG (at least if you don't care about any metadata that might have been included in the PNG file). Two tips for early adopters though: 1) don't convert lossy formats like JPEG to FLIF, because you'll waste a lot of bytes on losslessly storing the artifacts of lossy compression; 2) if you use the lossy encoding feature of FLIF, also keep the original lossless image around, because it's likely that the lossy encoder will still improve in the future.
With potential storage and bandwidth saving benefits, are the practical implications of browser render speed and browser support even that important?
Decode speed is important, especially for locally available files (e.g. images that are already downloaded and in the browser cache) where it is the main bottleneck for render speed. There are two things that make FLIF relatively slow: the algorithm itself inherently has a worse computational complexity than simpler formats like PNG, and its current implementation is not as optimized as the popular implementations of JPEG and PNG. So it is certainly something that we keep in mind when experimenting with the format specification. FLIF could certainly become a format used for archiving and for any use case where bandwidth (or storage) is the main bottleneck or cost.
What is outlook on browser support? Adoption of new image formats is always a bit of a chicken and egg problem: people can only really use a format if it is widely supported by browsers and other applications (so as an end-user, you might want to wait until that happens), but applications only tend to support formats that are already widely used (so as an application developer, you might want to wait until that happens). This is why there's typically some inertia to overcome when new formats are proposed.
Luckily, things are better now than they used to be. Thanks to Javascript, which has near-universal support and is becoming more and more performant, native browser support is not strictly needed (though still preferred). Thanks to Accept headers, browsers that would natively support FLIF can indicate so, and servers that do something like Cloudinary's automatic format negotiation ("f_auto") can serve FLIF images to browsers that support them, while still serving PNG or WebP to browsers that don't.
So I'm hopeful that despite the inevitable format inertia, FLIF will see some adoption in the relatively near future.
Top comments (0)