New issue
Advanced search Search tips

Issue 793683 link

Starred by 6 users

Issue metadata

Status: Available
Owner: ----
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 2
Type: Feature

Sign in to add a comment

Support for the FLIF image format

Reported by, Dec 10 2017

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36

Steps to reproduce the problem:
Chromium does not support the FLIF image/animation format.

What is the expected behavior?
Since it's an open, free, patent-free format designated for the web, I would expect chromium to support it in the future.

What went wrong?
Does not apply here.

Did this work before? No 

Chrome version: 62.0.3202.94  Channel: stable
OS Version: Arch Linux
Flash Version: 

The FLIF image/animation format which eliminates the generation loss, currently very present on JPG as well as lossy WebP. It features a very fast decompression time,

It compresses better than any other lossless image compression format while providing very early access to its content on a partial download, compared to progressive JPG as well as interlaced png on the same amount of downloaded data.


50 KB

250 KB

There's also a dynamic test (which works with a small javascript library for decoding):

So the most interesting feature is, to add the same file at different locations on a website, let the browser determine how much data is probably enough to show a given display size and if the device is rotated or the user clicked on that image to fetch more data, the data for the preview can just be used and some additional data could be fetched to render a larger display size.

Flif supports also animations with a progressive decoding of the full animation length as well as large color gamut/HDR by 16-bit channels and integrated ICC profiles as well as RAW-Images.


I started a discussion for Wikipedia Commons, but the lack of browser support is a huge drawback to think about adding it as a new format for saving pictures lossless in the future, avoiding the generation loss.


There was a feature request two years ago, but it was closed due it's unfinished, nonmature nature of FLIF at this time and has never been reopened.

So I try it once a again with a fresh start for the discussion, the old closed feature request from 2015 is #539120.

Any further information about this format can be found on: or
Components: Blink>Image
Labels: Needs-Triage-M62 Triaged-ET M-65
Status: Untriaged (was: Unconfirmed)
The issue seems to be a feature request. Hence, marking it as untriaged for further inputs from dev team.

Components: -Blink>Image Internals>Images>Codecs
Labels: -M-65 -Needs-Triage-M62 OS-Android OS-Chrome OS-Mac OS-Windows
Status: Available (was: Untriaged)
I've looked at the GitHub page and the info page and there are still plenty of reasons why we would not implement FLIF. Image decode speeds is something that already leads to significant scrolling performance problems, so there is essentially no way we are going to implement anything more costly.

The decode times cited in are still way to high. We have on the order of 16ms per frame to do everything, and pages very often have more than 1 image. This format would kill performance. Optimize it, and reduce the number of crash and security bugs you have, and come back to us.

Also note that various progressive download options are not supported in chromium right now, so taking advantage of that is a huge amount of work.

APNG support finally landed because someone provided proof of concept libraries that could be integrated into chrome (if I recall correctly). Given our current architecture you would need to write a decoder for the skia codebase, because that is where we do most decoding now.
> There was a feature request two years ago, but it was closed due it's
> unfinished, nonmature nature of FLIF at this time and has never been
> reopened.

That was one reason, but pkasting@ made another good point (in 
"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."

> APNG support finally landed because someone provided proof of concept libraries
> that could be integrated into chrome (if I recall correctly).

That definitely didn't hurt, but the fact that other browsers supported it had an influence.

> Given our current architecture you would need to write a decoder for the skia
> codebase, because that is where we do most decoding now.

This is actually not true (yet).

Comment 4 by, Dec 14 2017

Hey schenney,

I have no issues scrolling at this page[1], even while loading in Chrome, and my notebook is pretty old: Intel(R) Core(TM) i3-2330M CPU @ 2.20GHz with Intel graphics.

Since this is just a FLIF via Javascript to HTML5 canvas decoding, a native one should be no issue here.

I did a small benchmark for you:

I took two POTD from commons[2][3] and encoded them to PNG and encoded and decoded them as FLIF in two different sizes. PNG is the current competitor if we talk about a widespread lossless web-compatible image format.

The first image size (small) is this one used on the front page of commons, it's 500x284px for [2] and 499x295px for [3]. The second one is the original resolution, which is 7122x4048px for [2] and 5183x3063px for [3].

(conversion with imagemagick and flif)

## [2] with 0.142mpx ##

PAM to PNG    : 161ms (-quality 95)
PAM to FLIF-0 :  84ms (--effort=0 --interlace)
PAM to FLIF-60: 812ms (--effort=60 --interlace)

size PNG    : 239,512 Bytes
size FLIF-0 : 157,894 Bytes
size FLIF-60: 139,108 Bytes

PNG to PAM    : 24ms
FLIF-0 to PAM : 58ms
FLIF-60 to PAM: 81ms

## [2] with 28.829mpx ##

PAM to PNG    : 1m 7.681s (-quality 95  -interlace PNG)
PAM to FLIF-0 : 0m13.998s (--effort=0  --interlace)
PAM to FLIF-60: 3m21.040s (--effort=60 --interlace)

size PNG    : 32,860,948 Bytes 
size FLIF-0 : 20,473,644 Bytes
size FLIF-60: 14,850,679 Bytes

PNG2PAM       :  2,792ms
FLIF-0 to PAM :  9,174ms
FLIF-60 to PAM: 20,300ms

## [3] with 0.147mpx ##

PAM to PNG    : 141ms (-quality 95  -interlace PNG)
PAM to FLIF-0 :  88ms (--effort  0 --interlace)
PAM to FLIF-60: 859ms (--effort 60 --interlace)

size PNG    : 255,657 Bytes
size FLIF-0 : 166,951 Bytes
size FLIF-60: 146,545 Bytes

PNG to PAM    : 22ms 
FLIF-0 to PAM : 65ms 
FLIF-60 to PAM: 88ms 

## [3] with 15.875mpx ##

PAM to PNG    :   35.452s (-quality 95  -interlace PNG)
PAM to FLIF-0 : 0m 8,894s (--effort=0  --interlace)
PAM to FLIF-60: 2m15.440s (--effort=60 --interlace)

PAM to PNG    : 26,782,530 Bytes
PAM to FLIF-0 : 18,219,151 Bytes
PAM to FLIF-60: 15,138,922 Bytes

PNG to PAM    :  1.511s
FLIF-0 to PAM :  6,158s
FLIF-60 to PAM: 12.679s

[2] File:Estación_Central,_Berlín,_Alemania,_2016-04-21,_DD_43-45_HDR.JPG
[3] File:Eerste_zonnestralen_strijken_over_een_winters_landschap._Pad_tussen_Put_van_Nederhorst_en_Langweerderwielen._Locatie,_Langweerderwielen_(Langwarder_Wielen)_en_omgeving_01.jpg

I fully understand, if you think this would kill performance, but keep in mind the FLIF implementation is currently not optimized for speed. Feel free to contribute any optimization you like. :)

But my conclusion would be, an increase from 22ms to 58ms isn't a big deal, if the download takes just half as long for the same file. Especially on mobile networks, there is more computing power available than bandwidth - that's the reason why Chrome has a bandwidth-saving mode like Opera has too.

Keep in mind, that we doesn't need to load the full file, while it's still smaller than PNG, to get the output-size you need.

Best regards

I too want to pledge my support for this to be implemented.

From personal experience, FLIF outperforms the majority of codecs in-terms of filesize and initialisation of the first frame.

My opinion is should support be added, it should be selected based-upon hardware capability with a fallback to traditional formats.

<flif src="\image.flif" fallback="\image.png" cover="\cover.jpg" size="1280x720" aspect="16:9" awaitFrames=true />

src -
The path of a .FLIF image file (for modern devices)

fallback -
The path of a traditional format (.png , .gif , etc ) for older hardware.

cover -
The path of an image to display whilst obtaining first frame (or frames)

size -
Dimensions of which to display the image split by the character 'x' [W x H] for scaling the size.

aspect -
The ratio of the image to help maintain scaling.

awaitFrames -
A boolean to indicate whether to begin upon completion of the first frame or to wait for the entire image to have downloaded prior to playback.

Lastly, should my idea be considered; a benchmark of hardware specifications to identify suitability as to meet the guidelines would be useful.

Kind Regards,


Sign in to add a comment