Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 539120 Feature-Request: FLIF-Support
Starred by 17 users Reported by cyr...@gmail.com, Oct 4 2015 Back to list
Status: WontFix
Owner: ----
Closed: Dec 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Feature



Sign in to add a comment
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:

http://flif.info
 
Comment 1 by cyr...@gmail.com, 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:
https://imgur.com/vkfgL5Q

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

The original image can be found here:
https://imgur.com/afg0n51

Conclusion is, that on this very large image 2% of download is enouth for a SVGA-Preview.
Labels: -Type-Bug Type-Feature M-47
Status: Untriaged
Confirming the above issue as Feature-Request and marking it as untriaged.

Cc: pkasting@chromium.org
Labels: Cr-Blink-Image
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.
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).
hope this get implemented soon. great image format!
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  https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/image-optimization

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 more...it is Image(Data + Data) effectivly you load an image once, today you need 77kb Javascript to archive that (it will render as canvas) Example: https://uprootlabs.github.io/poly-flif/

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.
"Once FLIF is a stable format and has either implemented or
intentionally WONTFIXed all TODOs, it might be possible to reconsider
it."

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

Ruben

2017-01-10 17:03 GMT+01:00 marie.sc… via monorail
<monorail+v2.2984324424@chromium.org>:
Comment 9 Deleted
Comment 10 Deleted
"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.
Sign in to add a comment