|Issue 539120||Feature-Request: FLIF-Support|
|Starred by 20 users||Reported by cyr...@gmail.com, Oct 4 2015||Back to list|
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
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.
Oct 5 2015,
Confirming the above issue as Feature-Request and marking it as untriaged.
Dec 14 2015,
Dec 14 2015,
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.
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).
hope this get implemented soon. great image format!
"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.
Apr 19 (6 days ago),
> 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.
Apr 21 (4 days ago),
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.
|► Sign in to add a comment|