New issue
Advanced search Search tips
Starred by 4 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
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 cyr...@gmail.com, 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.

Example:

50 KB
https://imgur.com/a/84RbJ

250 KB
https://imgur.com/a/twXxr

There's also a dynamic test (which works with a small javascript library for decoding):
https://uprootlabs.github.io/poly-flif/

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:

http://flif.info or https://github.com/FLIF-hub/FLIF
 
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.

Thanks...!!
Cc: scroggo@chromium.org pkasting@chromium.org
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 https://bugs.chromium.org/p/chromium/issues/detail?id=539120 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 
https://bugs.chromium.org/p/chromium/issues/detail?id=539120#c4): 
"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 cyr...@gmail.com, 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

[1] http://flif.info/example.html
[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

Ruben

Sign in to add a comment