FLIF – Free Lossless Image Format

Always cool to see new visual compression libraries hit the scene. That said I think the hardest part isn&#x27;t the math of it, but the adoption of it.<p>Likely the format with the best chance of overthrowing the jpg&#x2F;gif&#x2F;png incumbents is AVIF. Since it&#x27;s based on AV1, you&#x27;d get hardware acceleration for decoding&#x2F;encoding once it starts becoming a standard, and browser support will be trivial to add once AV1 has wide support.<p>Compression wise AVIF is performing at about the same level as FLIF (15-25% better than webp, depending on the image), and is also royalty free. The leg it has upon FLIF is the Alliance for Open Media[1] is behind it, which is a consortium of companies including: &quot;Amazon, Apple, ARM, Cisco, Facebook, Google, IBM, Intel Corporation, Microsoft, Mozilla, Netflix, Nvidia, Samsung Electronics and Tencent.&quot;<p>I&#x27;m really excited for it and I hope it actually gets traction. It&#x27;d be lovely to have photos &#x2F; screenshots &#x2F; gifs all able to share a common format.<p>[1] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Alliance_for_Open_Media" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Alliance_for_Open_Media</a>

In terms of getting it into chrome: <a href="https:&#x2F;&#x2F;bugs.chromium.org&#x2F;p&#x2F;chromium&#x2F;issues&#x2F;detail?id=539120" rel="nofollow">https:&#x2F;&#x2F;bugs.chromium.org&#x2F;p&#x2F;chromium&#x2F;issues&#x2F;detail?id=539120</a><p>&gt; Keep in mind that the author of the FLIF works on the new FUIF (<a href="https:&#x2F;&#x2F;github.com&#x2F;cloudinary&#x2F;fuif" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;cloudinary&#x2F;fuif</a>) which will be part of the JPEG XL. So, probably FLIF will be deprecated soon. And as far as JPEG XL is also based on Google PIX, there is a high probability that Google will support this new format in their Blink engine.<p><a href="https:&#x2F;&#x2F;jpeg.org&#x2F;jpegxl&#x2F;index.html" rel="nofollow">https:&#x2F;&#x2F;jpeg.org&#x2F;jpegxl&#x2F;index.html</a>

FLIF author here. I have been working on FUIF and JPEG XL the past two years. FUIF is based on FLIF but is better at lossy. JPEG XL is a combination of Google&#x27;s PIK (~VarDCT mode) and FUIF (~Modular mode). You&#x27;ll be able to mix both codecs for a single image, e.g. VarDCT for the photo parts, Modular for the non-photo parts and to encode the DC (1:8) in a super-progressive way.<p>I&#x27;m very excited about JPEG XL, it&#x27;s a great codec that has all the technical ingredients to replace JPEG, PNG and GIF. We are close to finalizing the bitstream and standardizing it (ISO&#x2F;IEC 18181). Now let&#x27;s hope it will get adoption!

It looks like the the creator (Jon Sneyers) has since (2019) made another image format more focused on the lossy compression, FUIF[0], which itself has been subsumed by the JPEG XL format[1]. I hope the &quot;JPEG&quot; branding doesn&#x27;t make folks think that JPEG XL isn&#x27;t also a lossless format!<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;cloudinary&#x2F;fuif" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;cloudinary&#x2F;fuif</a> [1] <a href="https:&#x2F;&#x2F;jpeg.org&#x2F;jpegxl&#x2F;index.html" rel="nofollow">https:&#x2F;&#x2F;jpeg.org&#x2F;jpegxl&#x2F;index.html</a>

Yet, I think it&#x27;s really hard to change what has stuck. The gains have to be enormous to warrant the hassle of trying to keep publishing in and supporting a new image format until it just works for everyone.<p>The reason we have PNG and JPEG is that they are, all in all, more than good enough. Yes, the dreaded &quot;good enough&quot; argument surfaces again stronger than ever. They are also easy to understand, i.e. use JPEG for lossy photos and PNG for pixel-exact graphics. But most importantly they both compress substantially in comparison to uncompressed images (like TIFF) and both have long ago reached the level of compression where improving compression is mostly about diminishing gains.<p>As there&#x27;s less and less data left to compress further the compression ratio would need to go higher and higher for the new algorithm to make even a dent in JPEG or PNG in any practical sense.<p>Also, image compression algorithms try to solve a problem that has been gradually made less and less important each year with faster network connections. Improvements in image compression efficiency are way outrun by improvements in the network bandwidth in the last 20 years. The available memory and disk space have grown enormously as well.<p>For example, it&#x27;s not so much of a problem if a background image of a website compresses down to 500Kb rather than 400Kb because the web page itself is 10M and always takes 10 seconds to load regardless of which decade it is. If you could squeeze a half-a-megabyte off the website&#x27;s image data the site wouldn&#x27;t effectively be any faster because of that (but maybe marginally so to allow the publisher to add another half-a-megabyte of ads or other useless crap instead.

The section &quot;Works on any kind of image&quot; is really misleading, as it mentions JPEG as a lossy format (alongside JPEG 2000) then says &quot;FLIF beats anything else in all categories.&quot;<p>It really needs a giant caveat saying &quot;lossless&quot;. I mean, that&#x27;s still great and impressive, but it clearly doesn&#x27;t erase the need for a user to switch formats as a lossless format is still not suitable for end users a lot of the time.<p>(It does have a lossy mode, detailed on another page, but they clearly show it doesn&#x27;t have the same advantage over other formats there.)

The very obvious thing missing from the site is decode and encode benchmarks. Its very context dependent but if it had a long decode time, that could outweigh the bandwidth savings.

They have a polyfill for browsers:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;UprootLabs&#x2F;poly-flif" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;UprootLabs&#x2F;poly-flif</a><p>It weights 77kB gzipped which is a no-no in my book. Jesus, my current Mithril SPA weights 37kB gzipped. Not the JS bundle, the complete application.

Jon Sneyers, the creator of FLIF speaking about Jpeg XL<p><a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=lqi5U6dxeZU" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=lqi5U6dxeZU</a>

&gt; 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.<p>I wonder if tANS [0] could be used instead of arithmetic coding for (presumably) higher performance. Although I guess the authors must be aware of ANS. Would be interesting to hear why it wasn&#x27;t used instead.<p>[0]: Tabled asymmetric numeral systems <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Asymmetric_numeral_systems#tANS" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Asymmetric_numeral_systems#tAN...</a>

Seems really cool. It seems that the biggest gatekeepers for image formats are Apple and Google because of iPhone&#x2F;Safari and Android&#x2F;Chrome.<p>Basically, if you want to be able to easily view the image on a mobile device or on the web, the format needs their blessing.

I want to root for it but I think the LGPL license ruins it as long as there are BSD or MIT licenses alternatives that are good enough. Firefox might implement it but I think there’s zero change that Chromium or Safari add support.

I use this to store archives of scanned documents. The last thing I want is to scan something only to later find some subtle image artifact corruption (remember that case of copy machines modifying numbers by swapping glyphs?). I store checksums and a static flif binary along with the archive. It&#x27;s definitely overkill, but a huge win compared to stacks of paper sitting around.<p>My intuition was informed by choosing FLAC for my music collection ~15 years ago, and that working out fantastically. If a better format does come along, or if I change my mind, I can always transcode.

Before Apple&#x2F;Google&#x2F;Mozilla adopt in their browsers, I doubt this will get any traction.

Related from 2016: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=12626451" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=12626451</a><p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=11238190" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=11238190</a><p>2015: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=10317790" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=10317790</a>

I wonder how it compares with simply LZMA&#x27;ing (i.e. 7zip) a BMP. In my experience that has always been significantly smaller than PNG (which is itself a low bar --- deflate&#x2F;zlib is a simple LZ+Huffman variant which is nowhere near the top of general-purpose lossless compression algorithms.)<p>Along the same lines, I suspect BMP+LZMA would likely be beaten by BMP+PPM or BMP+PAQ, the current extreme in general-purpose compression.

Sorry to ask a very ametuerish question, but how is lossless compression of an image different from regular run of the mill compression (zip, 7z)? Is there any sort of underlying pattern or feature which is unique to image data that is leveraged&#x2F;exploited for lossless image compression?

Looks great. What about decoding and encoding speed?

Pretty cool, but where are the links to the issues on mozilla, chromium, webkit, and edge&#x27;s bug trackers to add native support for it?<p>As an unencumbered open source technology, it should breeze through legal&#x27;s OK pretty quickly, and getting it integrated could certainly take a bit of time, but should just be part of the FLIF roadmap itself, if the idea is to actually get this adopted.<p>You don&#x27;t set out to come up with &quot;one format to rule them all&quot; and then not also go &quot;by implementing libflif and sending patches upstream to all the open source browsers that we want to see it used in&quot; =)

I&#x27;d be interested in a format that can replace TIFF, without the files being quite so enormous. However, it seems like all the FLIF tools are assuming you&#x27;re coming from PNG-land.

The progressive loading video is great!

It sure looks impressive. I think it&#x27;s important to remember that comparing it to a lossy format will show it&#x27;s disadvantages. For example on this demo:<p><a href="https:&#x2F;&#x2F;uprootlabs.github.io&#x2F;poly-flif&#x2F;" rel="nofollow">https:&#x2F;&#x2F;uprootlabs.github.io&#x2F;poly-flif&#x2F;</a><p>If you compare with &quot;same size JPG&quot; and set the truncation to 80%, JPG appears to win out in terms of clarity of the image.

Introducing better compression of images and animations would be another small step fighting climate change. Less data, less transfer, less energy consumption!<p><a href="https:&#x2F;&#x2F;www.dw.com&#x2F;en&#x2F;is-netflix-bad-for-the-environment-how-streaming-video-contributes-to-climate-change&#x2F;a-49556716" rel="nofollow">https:&#x2F;&#x2F;www.dw.com&#x2F;en&#x2F;is-netflix-bad-for-the-environment-how...</a>

Could you end up with a lossy format just by truncating a FLIF? The Adam7 comparison shows it as looking reasonable at about 5% transfer.

Checklist for how far it should go to be accepted format, applicable to JPEG XL too:<p>- SIMD-optimised encoder&#x2F;decoder for major programming languages;<p>- stable photoshop and gimp import&#x2F;export plugins, supporting layers, animation and transparency features;<p>- metadata reading&#x2F;writing library for major programming languages;<p>- firefox and chrome integration at least.

It would be great to use this format for offline Wikipedia in Kiwix. This would substantially reduce its size...

Chromium has a pluggable interface for image formats. Add it to the Chromium source tree, and you get support in Opera, Chrome, and Edge.<p>Simply search &quot;webp&quot; in the codebase, and you can add another format like that.<p>I wonder if the Chromium developers would accept a patch for it?

<a href="https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20200207000006&#x2F;https:&#x2F;&#x2F;flif.info&#x2F;" rel="nofollow">https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20200207000006&#x2F;https:&#x2F;&#x2F;flif.info...</a>

you could have done &quot;free lossless image compression&quot; to have Flic-(Flac)

I have already converted all my JPEGs to WebP and configured my camera app to save directly to WebP. I hope one day I will be able to switch to FLIF the same way.

If only it could focus the progressive download on areas of the picture, so it details faces in the early part of the file, and background in the later part.

MacOS viewer does not work at all on any of the test images. Gives error &quot;The document “5_webp_ll.flif” could not be opened.&quot;

The upcoming, ubiquitous next gen codec, JPEG XR is heavily influenced by FLIF and is co-created by it&#x27;s founder.

Very cool, hoping to see more of this in the future. Good job team

We need this! :)

Isn&#x27;t making it LGPL a problem? That means anything that touches it becomes LGPL, right?

Not a nice idea to do reference implementation in C++ instead of C!

Little mention of alpha encoding, something PNG absolutely botched. Unsurprising.