New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 47 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Dec 2015
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Feature

Sign in to add a comment

Issue 539120: Feature-Request: FLIF-Support

Reported by, Oct 4 2015

Issue description

UserAgent: Mozilla/5.0 (iPhone; CPU iPhone OS 9_0_2 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13A452 Safari/601.1

Steps to reproduce the problem:
Chromium does not support the new FLIF-Format yet.

What is the expected behavior?
Support for FLIF would be nice!

What went wrong?
Does not apply.

Did this work before? No 

Chrome version: Latest  Channel: stable
OS Version: All
Flash Version: 

FLIF is a new Image-Format which works lossless. Else it supports very good preview of partial-downloaded images, so it is possible to limit the downloads of images to a percentage-size on mobiles, to use lossy compressions where necessary.

Else FLIF has better compression ratios than PNG/JPG2000 lossless/WebP-Lessless and all other lossless-formats. It looks better than JPG progressive on same partial download-size and does have relatively good compression/decompression times.

All informations can be found here:

Comment 1 by, Oct 4 2015

To show the differences between JPG and FLIF.

I loaded a PNG (4752x2418 pixel) of 6,6 MByte in FLIF, which resultes in 3,8 MByte (transcode-time: 1m43s on a i3 2nd gen).

Now I cutted the first 73 KByte of the file, and decoded them. This results in the following image:

Now I transcoded the original image to JPG and slided on the quality as long as 73 KByte is achieved. Here is the JPG:

The original image can be found here:

Conclusion is, that on this very large image 2% of download is enouth for a SVGA-Preview.

Comment 2 by, Oct 5 2015

Labels: -Type-Bug Type-Feature M-47
Status: Untriaged
Confirming the above issue as Feature-Request and marking it as untriaged.

Comment 3 by, Dec 14 2015

Labels: Cr-Blink-Image

Comment 4 by, Dec 14 2015

Status: WontFix
The bar to get a new image format into Chromium is incredibly high.  (For example, note that we still don't support APNG despite Firefox supporting it for years.)

While we're not ruling out ever supporting this format, it's not really appropriate for consideration yet.  The format's own homepage notes numerous major TODOs that would need to be addressed to consider this.

Once FLIF is a stable format and has either implemented or intentionally WONTFIXed all TODOs, it might be possible to reconsider it.  However, rather than raising this directly in Chrome's bug tracker, this should be brought up as a general discussion across all browser vendors, since if possible the vendors should try to reach agreement on whether this is compelling.  At that point it would be very helpful to have evidence of strong web author desire for this.  Good compression ratios are important, but so are numerous other factors.

Comment 5 by, Mar 7 2016

Which TODOs would you need to see implemented or crossed off?

I think supporting the format in Chrome would help drive adoption. The image format has the potential to greatly reduce page load times and reduce total bandwidth used on image heavy sites (ie, pretty much every site).

Comment 6 by, Jan 10 2017

hope this get implemented soon. great image format!

Comment 7 by, Jan 10 2017

I'd like to deliver some "evidence" that Webauthors are highly interested in fixing this. Cause:

the alternative to flif is javascript and maybe 5 different image sizes (based on the amount of media queries and platforms you are maintaining ) in order to replace a low data image with a matching size for the platform.

A bit of evidence how much attention Google pays

E.g. the Google cultural institute. Equiped with high resolution images its logical not to deliver them on a mobile device. Except requested. What you do is, you let a server do the trick, resize png's and replace them if requested and depending on its platform. Which is image data + image data.

Flif delivers the data you need, and if you need is Image(Data + Data) effectivly you load an image once, today you need 77kb Javascript to archive that (it will render as canvas) Example:

A very common usecase could be a device rotation. While a portrait device maybe needs just 20kb per image thumbnail...a landscape situation might like 40kb. Cause responsive design is giving them more space, they appear bigger. I can use more traffik and go with the landscape resolution or I can go with portrait and get terribly looking pngs, or I could have 10 different sizes and double my traffik.

In any case, the flif solution is data sensitive. A native implementation would save 80kb js and I would appreciate a more detailed Information which metrics should be met in order to implement this.

best, just a very interested webauthor.

Comment 8 by, Jan 15 2017

"Once FLIF is a stable format and has either implemented or
intentionally WONTFIXed all TODOs, it might be possible to reconsider

I think it's time. ImageMagick supports FLIF and there's a javascript
library to support browsers with backward compatibility. The most
development is done and since it's already implemented in different
software, this is to be considered future safe if we implement the
current version of the format.

So please remove the "WontFix" tag as promised.

Best regards


2017-01-10 17:03 GMT+01:00… via monorail

Comment 9 Deleted

Comment 10 Deleted

Comment 11 by, Feb 3 2017

"The bar to get a new image format into Chromium is incredibly high."...

I really do like FLIF, but FLIF'S author is competing with Google as the main promoter of WebP - which is is fast, has ok lossy and good lossless compression.

Even if it's better than XR or 2K, FLIF might need have very good reasons to merit its inclusion. Alas, some of its strengths like no generation loss and high bit depths aren't critical for Internet usage. Plus atm(!) it's slow and compression isn't that revolutionary for general photographic images vs. pre-processed near-lossless webp.

That leaves us with FLIF in a browser as a PNG-ish replacement for other image types than photography ... certainly nice to have, but I'm personally using it as a offline format for image editing and adoption for gimp and ps seems more critical to me. Ymmv.

Comment 12 by, Apr 19 2017

> Alas, some of its strengths like no generation loss and high bit depths aren't critical for Internet usage.

Actually, if you look at humorous images that are posted on a lot of high-profile websites, you'll swiftly notice that their quality is rather lackluster - and it's a simple result of people sharing and reuploading images from one provider to another, over and over again. Since some providers insist on using lossy JPEG instead of a lossless format like PNG, this leads to a continuous degradation of image quality until you end up with something like the image in the attachment.

Lossy FLIF not just creates less compression artifacts than JPEG does, these images can also be compressed over and over again hundreds of times without losing any significant degree of quality or peaking artifact effects. Furthermore, lossy FLIF can outperform JPEGs in file size for equivalent quality (signal noise ratio), saving bandwidth costs - and since even lossless FLIF outperforms the lossless PNG format, site owners can may consider it an alternative to JPEG to make their content appear more qualitative.

I believe the inclusion of FLIF in major browsers would make everyone happy: Users because their content loads faster and looks better; especially when FLIF's decompressor, which currently is a reference implementation (i.e. easy to read and lacking optimizations), will be ported to specific platforms and optimized to make it perform as fast as possible. Site owners will be happy about the reduced traffic costs, easier content delivery and development (any range 0-n bytes of a FLIF file constitutes a valid image which is great for responsive images and makes having several different resolution versions of an image unnecessary), and, in return, happier users.
153 KB View Download

Comment 13 by, Apr 21 2017

Another argument for FLIF implementation additionally to WebP is: We shall not decide which format is the best solution for the web. There has been always competition on the web, like M4A vs OGG, h264 vs VP8, h265 vs VP9.

Correct me if I'm wrong, but Chromium/Chrome support all of them, to let the users and the time decide which format is best suitable for web.

Since Browser are at the time the mostly used way to consume media content, I think it's our role to be neutral and don't favor the Google format because it's from Google. That's the Microsoft way of thinking and time shows, this was wrong.

We saw here many arguments which prove, FLIF is indeed suitable for the Web, and especially with the ability to limit the maximal download size of an image, either as percentage or as maximum per image file.

If the user choose to download the image, it could be fetched the rest of the image and saved lossless in the download folder.

Also an easily reachable "fetch more" context entry on images would be also nice, if there are visible artifact.

 So still, FLIF should be included in Chromium, as a valid competitor to WebP.

Comment 14 by, May 6 2017

Another few things worth noting about the FLIF versus lossless WebP thing, and why "we already have webp" isn't a sufficient argument to not support FLIF:

1. FLIF has more features than (near) lossless WebP. There's genuine things that WebP can't do that FLIF can (such as requesting a scaled image directly from the decoder).

2. Lossy FLIF (i.e. near-lossless) performs comparably to Near Lossless WebP for lineart and screenshots and the like, but FLIF vastly outperforms near-lossless webp for photographs. Sure, lossy WebP works well with photographs, but you run into the Generation Loss issue again. 

This is especially since there isn't any real downside of adding FLIF support. FLIF is LGPL (or Apache 2.0 for the decoder-only library) and has no patent issues, and early adopters have the option of using Poly-FLIF for users with older browsers.

Comment 15 by, May 6 2017


Comment 16 by, May 10 2017

Just took a look at the comparison provided by the FLIF
guys, WebP doesn't look that suitable for animation if you ask me, sure they only tested two samples, but the compression size is way bigger. Even APNG is better than WebP in those cases.

I also wonder why WebP only not supports true color a 8-bit color space is pretty outdated, isn't it?

Even Windows uses deep color per default. With FLIF I'm able to produce content with 12 or 16 bit per channel and deliver it to the users while the graphic card then calculate the best output with the color profile and the available color depth.

With WebP I'm only able to deliver 8 bit which is upsampled to 10 bit again, after I destroyed those informations by saving it in WebP. Then the color profile is done on top of it. I don't see how this should look better than JPG. And for some percent better compression ratio a complete new format? I don't see here much advantages for WebP. Sorry guys.

WebP is absolute no-go for me, please implement FLIF it's a much better way to go for the future, since it supports the currently used color depth, not the Windows XP one.

Comment 17 by, May 14 2017

Well, not supported higher than 8-bit-per-channel depth is not exactly relevant here, because 24-bit color is still ubiquitous everywhere, and higher bit depth is less useful for the web. The monitor I purchased a two months ago uses 8-bit color, for example.

But yes, with respect to the animation, interlaced FLIF animations load more effectively than WebP animations. From the spec:

"Both in the interlaced and in the non-interlaced mode, the frames of an animation are interleaved at a relatively deep level of the nested loops. This means that progressive decoding of an animation does not result in the first few frames at full quality, but instead, you get all frames at reduced quality. In non-interlaced mode, early stages of progressive decoding will give you the top portion of all frames, only in grayscale (assuming the YCoCg color transformation). In interlaced mode, progressive decoding will give you a blurry / low resolution preview of the full animation."

Comment 18 by, May 16 2017

I don't think this argument is valid, we talk about a new file format which should serve the web for many years... so HDR should be a standard feature - regardless that there might be monitors still low dynamic range on the shelves.

Many LCDs and also some mobile phones already are HDR and I guess we're only 1-2 years away from this beeing the standard.

So Windows uses 12 bit where possible, so plugging in a HDR capable monitor would increase the color depth without user intervention.

As I already mentioned, the color depth of the picture format is also too low with 8 bit if the monitor is 8 bit, cause there are losses from the color calibration of the monitor. So you might end up with something below 7 bit as color depth.

To conclude: A format for the Web introduced at this time should be HDR-capable, else we could just use JPG for another decade.

Another point mentioned before is generation loss, WebP seems to have a HUGE issue with generation loss, even larger than JPG.

Comment 19 by, May 29 2017

I'd like to see this supported in Chrome by default. Great to have a completely royalty-free LGPL image well supported. Kinda important for the open web.

Comment 20 by, Jul 8 2017

please implement this image format. And the great thing is that it's free.

Comment 21 by, Jul 17 2017


Comment 22 by, Jul 31 2017

It is must have for HTML5 Instant Games, that has 5MB limitation. 
Please consider including it in Chrome.

Comment 23 by, Dec 11 2017

I just loaded the POTD from commons, which is currently:,_Berl%C3%ADn,_Alemania,_2016-04-21,_DD_43-45_HDR.JPG

I've encoded it with FLIF in the size which was shown on the webpage: 500x284 pixel and with applied ICC profile I converted it via GIMP to PNG.

So converting PNG to FLIF takes 835ms on a Intel(R) Core(TM) i3-2330M CPU @ 2.20GHz.

Decoding on the same machine back to PNG takes 119ms and without that compression overhead of PNG, saving it to '.pam' it takes 81ms.

I don't see any issue with that compressing or decompressing speed.

Comment 24 by, Feb 9 2018

Would love to see FLIF supported as well! Can we get more specificity as to what you would like to see improved before adoption? There's a whole community out here ready to help tackle some of those TODOs!

Comment 25 by, May 31 2018

Hello, FLIF is currently the best lossless image codec. Please add support for it.

Comment 26 by, Jul 29 2018

Currently building a PWA, and was researching image formats. It would be nice if newer formats such as BPG and FLIF were supported, so I wouldn't have to rely on a polyfill.

From my research, it seems that FLIF would be the most efficient solution for high quality photos downloading quickly.

Comment 27 by, Dec 9

Given its performance, I think it would make sense to support the FLIF image format.

Comment 28 by, Jan 1

If Comment 21 is in Chinese I'mma do this in German: Ich hoff' das wird endlich mal was, FLIF ist geil, tut etwas!

Sign in to add a comment