1240692 - (FLIF) Implement support for Free Lossless Image Format (FLIF)

Status: VERIFIED WONTFIX

(Core :: Graphics: ImageLib, enhancement, P3)

Description

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

More info here - http://flif.info/

Comment 1

[Jeff Muizelaar [:jrmuizel]]

Decode performance is a weakness of FLIF. See https://github.com/FLIF-hub/FLIF/issues/89

Comment 2

[Masatoshi Kimura [:emk]]

Will web authors have to upload FLIF for Firefox, JPEG XR for IE/Edge, WebP for Chrome, and JPEG 2000 for Safari? Excellent...

Comment 3

[oscarnardone]

(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

[frankhamand]

(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

Comment 5

[Vitor]

Should it actually be implemented? If so, may I be given this task?

Comment 6

[Jeff Muizelaar [:jrmuizel]]

(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

[Mozilla Marsu]

(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.

Comment 8

[avada]

(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.

Comment 9

[ruben]

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?

Comment 10

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

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.

Comment 11

[Kagami Rosylight [:saschanaz] (they/them)]

Note that the decoder got a significant performance boost last year. https://github.com/FLIF-hub/FLIF/issues/333#issuecomment-297516166

Comment 12

[naumovvladislav]

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

[Jeff Muizelaar [:jrmuizel]]

Are there comparisons of decoder performance vs webp?

Comment 14

[A.Horak]

Will you add it soon?

Comment 15

[Mozilla Marsu]

(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

[Valentin Born]

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!

Comment 17

[Kagami Rosylight [:saschanaz] (they/them)]

(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/

Comment 18

[Eric Shepherd [:sheppy]]

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.

Comment 19

[James Frost]

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

[Peter Gervai]

(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))

Comment 21

[Jeff Muizelaar [:jrmuizel]]

Indeed.