Closed
Bug 1240692
(FLIF)
Opened 9 years ago
Closed 4 years ago
Implement support for Free Lossless Image Format (FLIF)
Categories
(Core :: Graphics: ImageLib, enhancement, P3)
Core
Graphics: ImageLib
Tracking
()
VERIFIED
WONTFIX
People
(Reporter: Virtual, Unassigned)
References
()
Details
(Keywords: dev-doc-needed, feature, nightly-community, Whiteboard: [gfx-noted])
More info here - http://flif.info/
Flags: firefox-backlog?
Comment 1•9 years ago
|
||
Decode performance is a weakness of FLIF. See https://github.com/FLIF-hub/FLIF/issues/89
Updated•9 years ago
|
Whiteboard: [gfx-noted]
Comment 2•9 years ago
|
||
Will web authors have to upload FLIF for Firefox, JPEG XR for IE/Edge, WebP for Chrome, and JPEG 2000 for Safari? Excellent...
Reporter | ||
Updated•9 years ago
|
Alias: FLIF
Summary: (FLIF) Implement FLIF (Free Lossless Image Format) support → Implement FLIF (Free Lossless Image Format) support
Reporter | ||
Updated•9 years ago
|
Summary: Implement FLIF (Free Lossless Image Format) support → Implement support for Free Lossless Image Format (FLIF)
Reporter | ||
Updated•9 years ago
|
Reporter | ||
Updated•9 years ago
|
Comment 3•9 years ago
|
||
(In reply to Masatoshi Kimura [:emk] from comment #2)
> Will web authors have to upload FLIF for Firefox, JPEG XR for IE/Edge, WebP
> for Chrome, and JPEG 2000 for Safari? Excellent...
Not necessarily... according to information on http://flif.info , FLIF compresses on average ~20% better than any other well known lossless image codec. With savings this big, with the additional bonus of the image format being responsive and progressive by design, there's a good reason for multiple browser vendors to consider implementing this codec.
Comment 4•9 years ago
|
||
(In reply to oscarnardone from comment #3)
> (In reply to Masatoshi Kimura [:emk] from comment #2)
> > Will web authors have to upload FLIF for Firefox, JPEG XR for IE/Edge, WebP
> > for Chrome, and JPEG 2000 for Safari? Excellent...
>
> Not necessarily... according to information on http://flif.info , FLIF
> compresses on average ~20% better than any other well known lossless image
> codec. With savings this big, with the additional bonus of the image format
> being responsive and progressive by design, there's a good reason for
> multiple browser vendors to consider implementing this codec.
There's also good reason for multiple browser vendors to consider implementing webp, but it seems that's not going to happen any time soon
Reporter | ||
Updated•8 years ago
|
Has Regression Range: --- → irrelevant
Has STR: --- → irrelevant
Comment 6•8 years ago
|
||
(In reply to Vitor from comment #5)
> Should it actually be implemented? If so, may I be given this task?
I believe there are still concerns about decode performance.
Comment 7•8 years ago
|
||
(In reply to Masatoshi Kimura [:emk] from comment #2)
> Will web authors have to upload FLIF for Firefox, JPEG XR for IE/Edge, WebP
> for Chrome, and JPEG 2000 for Safari? Excellent...
Not necessarily, first off some browsers might become less important over time (not naming any specifically nor any reasons like abandoning most addons, mind you :-)).
* XR was DOA due to lackluster compression and MS knows it, thus no development there and now XT.
* 2K is complex/slow and high compression wavelets lack the visual "sharpness" of dct blocks.
Which leaves us with WebP, which is fast, has ok lossy and good (pre-processed or 100%) lossless compression. I really do like FLIF, but 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. 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.
Reporter | ||
Updated•8 years ago
|
Keywords: nightly-community
(In reply to oscarnardone from comment #3)
> (In reply to Masatoshi Kimura [:emk] from comment #2)
> > Will web authors have to upload FLIF for Firefox, JPEG XR for IE/Edge, WebP
> > for Chrome, and JPEG 2000 for Safari? Excellent...
>
> Not necessarily... according to information on http://flif.info , FLIF
> compresses on average ~20% better than any other well known lossless image
> codec. With savings this big, with the additional bonus of the image format
> being responsive and progressive by design, there's a good reason for
> multiple browser vendors to consider implementing this codec.
I don't think it has any chance of widespread support without somehow getting accepted by the IETF, and for that the support of Google might be needed. A lot of convincing needs to happen.
Reporter | ||
Updated•7 years ago
|
QA Contact: Virtual
Updated•7 years ago
|
Priority: -- → P3
I just loaded the POTD from commons, which is currently:
https://commons.wikimedia.org/wiki/File:Estaci%C3%B3n_Central,_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.
Furthermore that compression format is very interesting for the web, because of it's ability to decode partitial downloads with lower resolution. Means the same image must just stored once and can be loaded at the right amout for the display size.
It also supports animations with alpha channels and also the ability to store HDR images is a must-have for the next generation image format for the web.
WebP never took off and I don't think it ever will, because of the HUGE generation loss included.
Here is a example how a partital download and lower resolution rendering for thumbnails might look like... keep in mind, this is currently rendered in JavaScript.
https://uprootlabs.github.io/poly-flif/polyflif-sample.html
---
Is there any roadmap, when can we expect a FLIF support in Firefox?
Flags: needinfo?(Virtual)
Reporter | ||
Comment 10•7 years ago
|
||
It's still as "?" value for being included to Firefox backlog, so there is no any roadmap for FLIF support in Firefox unfortunately yet. What's more, please see comment #1 and comment #6.
Flags: needinfo?(Virtual)
Note that the decoder got a significant performance boost last year. https://github.com/FLIF-hub/FLIF/issues/333#issuecomment-297516166
Comment 12•7 years ago
|
||
I think that it's benefits - better compression, support of all types pictures, ability to act like preview and full image in one file.
Hope, it will be included in Firefox.
I don't see any reasons for it not to be included into Firefox.
Comment 13•7 years ago
|
||
Are there comparisons of decoder performance vs webp?
Comment 14•6 years ago
|
||
Will you add it soon?
Comment 15•6 years ago
|
||
(In reply to ruben from comment #9)
>
> WebP never took off and I don't think it ever will, because of the HUGE
> generation loss included.
>
> Is there any roadmap, when can we expect a FLIF support in Firefox?
>
Doing biased comparisons doesn't help - the fast webp (do notice the "web" part) is just fine for one-time lossy compression internet usage. That's because webp features a very efficient lossless mode. And webp is backed by Google, who have embedded low-power devices and server power usage in mind. If webp doesn't take off it's because there's still not enough difference/demand vs. the current jpeg/png/gif combination atm.
I do appreciate the effort and compression innovation of flif. And I'd like to see the "one ring to rule them all" format as much as the next web designer or photog. Alas, flif doesn't seem to be the jpeg replacement, but rather handy for offline or png-ish web usage.
Comment 16•6 years ago
|
||
I don't care too much about the compression advantage (or the decoding processing, as that seems to be OK) β but the responsive part is a huge bonus! The βone format to rule them allβ a nice feature, too!
(In reply to Mozilla Marsu from comment #15)
> If webp doesn't take off it's because there's still not enough
> difference/demand vs. the current jpeg/png/gif combination atm.
It's taking off:
https://www.cnet.com/news/firefox-to-support-googles-webp-image-format-for-a-faster-web/
Reporter | ||
Updated•6 years ago
|
Type: defect → enhancement
Comment 18•5 years ago
•
|
||
Added dev-doc-needed, as if this format ever gets implemented, documentation, BCD, and possibly other databases (hopefully by then
we'll have a "file format compatibility" database) will need updating to recognize it.
Keywords: dev-doc-needed
Comment 19•4 years ago
|
||
I assume this can be closed given that this format's successor has been subsumed into JPEG XL, and the format itself never gained significant adoption.
Comment 20•4 years ago
|
||
(In reply to James Frost from comment #19)
I assume this can be closed given that this format's successor has been subsumed into JPEG XL, and the format itself never gained significant adoption.
Probably shall be closed in favour of bug #1539075 (Implement support for Next-Generation Image Compression (JPEG XL))
Reporter | ||
Updated•4 years ago
|
Status: RESOLVED → VERIFIED
Flags: firefox-backlog?
You need to log in
before you can comment on or make changes to this bug.
Description
•