FLIF - lossless image format claiming better compression than BPG, PNG or WebP

[mandarinka]

http://flif.info/

Hacker News thread with some clarifications from authors (nick
"jonsneyers"): https://news.ycombinator.com/item?id=10317790

Some discussion about the format/development can be read here: https://boards.openpandora.org/topic/18485-free-lossless-image-format-flif/?page=1

The animation support looks interesting, partially downloaded image can be decoded for lower quality full animation loop (= the animation can play before the file is fully downloaded)
http://flif.info/animation.php

[mariush]

The bitstream/format is not finalized yet (it's basically guaranteed to change in the future until it's frozen) and there's some other things still missing (like lack of various color spaces which i care about but others may not) so while it's interesting, there's still a lot of work to be done.

[Jamaika]

Where it can be downloaded. :helpful:

[foxyshadis]

No builds seem to be floating around yet.

It's very, very slow, almost as slow to encode as BPG (preset used unknown) and much slower to decode than anything else. Needs more eyes to test if it's actually 100% lossless, no rounding errors. I wouldn't take the "patent-free" claim at face value until someone better versed in patent law vets it. Still, it's a pretty interesting improvement on the state of the art, gains in the double-digits are nothing to sneeze at.

[Kurtnoise]

Where it can be downloaded. :helpful:
http://www.mediafire.com/download/2ijsvai6p29662v/FLIF-20151013.zip

[Bloax]

A photographic benchmark: http://qlic.altervista.org/LPCB.html
Another discussion: http://encode.ru/threads/2321-FLIF-Free-Lossless-Image-Format

It seems to do well compared to PNG on paletted sprites (https://dl.dropboxusercontent.com/u/63152810/n/crawl/agnes.png) and photographic images (https://dl.dropboxusercontent.com/u/63152810/romerocarmack.png), but on paletted textures (https://dl.dropboxusercontent.com/u/63152810/n/extradoom/heh/GOODDOOR.png) it falls behind pretty badly.

[Jamaika]

Many thanks.:cool:

It's very, very slow, almost as slow to encode as BPG (preset used unknown)...
It isn't so tragic for FLIF, just I don't know if this is lossless? BPG is faster on the codec X265, but for UltraHD size lossless image is larger than the compressed PNG. The installing application is pointless.

However, I have questions.
How do we know that FLIF is a "Free Lossless Image Format"?
Does the container FLIF supports alpha channel and image 16bit depth?
What does the message "Palete disabled"? After default is set to 512.
How does the lossy encode quality enable?
How does the viewer FLIF-d.exe use? I cann't find a files APPCRT140D.dll and DESKTOPCRT140D.dll

flif.exe -v -n -b -p512 -q100 input-3840x2160_RGBA.png output-3840x2160_RGB.flif
flif.exe -v -d -q100 -s1 output-3840x2160_RGB.flif armenia_teghut-wallpaper-3840x2160_RGB.png
Palette disabled
FLIF 0.1 [13 October 2015] (c) 2010-2015 J.Sneyers & P.Wuille, GNU GPL v3+
Loading input file: armenia_teghut-wallpaper-3840x2160_RGBA.png
Alpha channel not actually used, dropping it.
0% done [1/3] ENC[3840x2160]

https://www.sendspace.com/filegroup/tMGvu3eK3d49FpflYyiZ7zgWjdfHcGiT

[benwaggoner]

A photographic benchmark: http://qlic.altervista.org/LPCB.html
Another discussion: http://encode.ru/threads/2321-FLIF-Free-Lossless-Image-Format

It seems to do well compared to PNG on paletted sprites (https://dl.dropboxusercontent.com/u/63152810/n/crawl/agnes.png) and photographic images (https://dl.dropboxusercontent.com/u/63152810/romerocarmack.png), but on paletted textures (https://dl.dropboxusercontent.com/u/63152810/n/extradoom/heh/GOODDOOR.png) it falls behind pretty badly.
So, it's better than PNG at the things PNG isn't very good at :)?

I don't know that we need another lossless-only format. Ideally we'd have a format that can do both lossless or lossy depending on the content and file size requirements.

[Bloax]

So, it's better than PNG at the things PNG isn't very good at :)?

I don't know that we need another lossless-only format. Ideally we'd have a format that can do both lossless or lossy depending on the content and file size requirements.
Yes, while being beat at subjects PNG is good at. ;)

As for the lossless/lossy formats - so, BPG/WebP?

Personally then I'm curious as for whether or not GCIF (https://github.com/gameclosure/gcif) is in a usable state. I have an allergy to compiling things, and I haven't seen any binaries of it floating anywhere.
It's amazing how few people actually provide god damn binaries so that people can use their shit.

[BadFrame]

I wouldn't take the "patent-free" claim at face value until someone better versed in patent law vets it.

True, but atleast there's the chance that it does not, take by comparison something like BGP which we know is patented and therefor will never be supported on the web (no one will pay royalties to serve/support a new image format).

[BadFrame]

I don't know that we need another lossless-only format. Ideally we'd have a format that can do both lossless or lossy depending on the content and file size requirements.

The author posted a roadmap which had lossy encoding listed, so there's a decent chance it will be supported later.

Of course webp can do both, but personally I've only been impressed with the lossless webp results (which FLIF readily beats!), however webp is still being developed and I've read that there will be some decent compression improvements for the next release.

The problem is not being able to beat JPG or PNG, but to have it be supported across all browsers and preferably directly in operating systems, this means it must be royalty free and of course be so much better than the existing 'supported everywhere' formats that it becomes almost a no-brainer to pick up.

And even if all the above criterias are met, there's the politics involved between companies...

[Jamaika]

The problem is not being able to beat JPG or PNG, but to have it be supported across all browsers and preferably directly in operating systems, this means it must be royalty free and of course be so much better than the existing 'supported everywhere' formats that it becomes almost a no-brainer to pick up.

And even if all the above criterias are met, there's the politics involved between companies...
The facts are that Microsoft has somewhere competitors other companies and inadvertently support them. The exception Adobe Flash and Acrobat.
As for the photos was ridiculed for writing about BPG/WebP {qualification spam}. Image processing lossless and lossy is Adobe DNG format {JPEG lossy/lossless}. The rest shouldn't concern me and wasting her time. It is for the layman.

[smok3]

The problem is not being able to beat JPG or PNG, but to have it be supported across all browsers and preferably directly in operating systems, this means it must be royalty free and of course be so much better than the existing 'supported everywhere' formats that it becomes almost a no-brainer to pick up.

And even if all the above criterias are met, there's the politics involved between companies...

I imagine the browser support part can happen at higher level (bpg has a js decoder for example), so that shouldn't be such an issue in next decade.

[BadFrame]

I imagine the browser support part can happen at higher level (bpg has a js decoder for example), so that shouldn't be such an issue in next decade.

I fail to see how this would somehow avoid patent royalties ?

[Jamaika]

New encoder FLIF v0.1.6 beta
- add alpha channel,
- adding function resignation with alpha channel {-A}
- added the conversion for 16bit PNG images {-a},
- conversion only for 8bit FLIF images {-b},
- no support for lossy image quality {-q},
- viewer displays the max. size 960x540
http://encode.ru/threads/2321-FLIF-Free-Lossless-Image-Format/page3?

[Gravitator]

We look forward to adding to comparison > http://xooyoozoo.github.io/yolo-octo-bugfixes/#addpsy#

[xyzone]

I would be more interested in an animated image format with alpha transparency. It stinks that apng was rejected by the powers that be.

[Jamaika]

We look forward to adding to comparison > http://xooyoozoo.github.io/yolo-octo-bugfixes/#addpsy#
By the way could be added Daala. Would do well to write what percentage of quality is tiny, small, medium, large and how to write encoders for enthusiasts. ;)
https://people.xiph.org/~xiphmont/demo/daala/update1-tool2b.shtml
Test image lossless (https://www.sendspace.com/file/3uadgi)

[Gravitator]

The demo stand (available PNG and JPG for comparison)> http://uprootlabs.github.io/poly-flif/

[Jamaika]

:thanks:
Is it the latest version of the codec FliF and it updated?
Is you know where can I donwload new version codec?

[Gravitator]

:thanks:
Is it the latest version of the codec FliF and it updated?
Is you know where can I donwload new version codec?
Probably better to ask in the forum given above.
Uncomfortable that FliF developer is absent on doom9...

[Jamaika]

Time to start test codec FliF 2.0.rc13. Because that it is a lot of advertising about this good compression codec, you should check whether it is really so good. Recently, it has been enabled 'lossy'.
http://flif.info/example.html
For the test I used two files PNG 1920x1080 RGB24. One had a lot of flat surfaces second file was varied background with subtitles.
All files were compressed 250 and 125 times smaller than the original size. I wondered how such images they present.

Used codecs WebP v0.5 (old codec VP8), BPGv0.9.6 (old codec X265 1.8), FliF v2.0.r13 and Daala v0.0.1533.
File original:
http://i65.tinypic.com/2kj9dl.png
WebP(vp80) v0.5 YUV420, range limited, Q10, 51kb
http://i67.tinypic.com/4tvreu.jpg
BPG(x265) v0.9.6 RGB24, Q45, 51kb
http://i64.tinypic.com/5af7uw.jpg
Daala v0.0.1533 (01.04.2016) YUV444, Q55, 51kb
http://i63.tinypic.com/2howy0o.jpg
FliF v2.0.r13 (01.04.2016) RGB24, Q(-330), 51kb
http://i65.tinypic.com/29givqu.jpg
File original:
http://i63.tinypic.com/20jin1v.png
Stream #0:0: Video: webp(vp80) v0.5, yuv420p(tv(range limited), bt470bg/unknown/unknown), 1920x1080, 25 tbr, 25 tbn, 25 tbc, Q28, 25kb
http://i67.tinypic.com/2ds37fc.jpg
Stream #0:0: Video: bpg(x265) v0.9.6, rgb24(pc(range full), unknown/unknown/unknown), 1920x1080, 25 tbr, 25 tbn, 25 tbc, Q41, 25kb
http://i68.tinypic.com/kb6stw.jpg
Stream #0:0: Video: daala v0.0.1533 (01.04.2016), yuv444p, 1920x1080, SAR 1:1 DAR 16:9, 25 tbr, 25 tbn, 25 tbc, Q47, 25kb
http://i64.tinypic.com/wa6q3d.jpg
Stream #0:0: Video: flif v2.0.r13 (01.04.2016), rgb24i, 1920x1080, Q(-255), 25kb
http://i65.tinypic.com/2crv7uv.jpg

Conclusions: Each alone can itself be deduced.

[Bloax]

FLIF seems to suffer from extreme edge fuzziness (at those extreme sizes) - just look at the lamp's foot or the table - which is not a good thing and has therefore been a priority to fix for the other algorithms.

[BadFrame]

Interesting results, Daala looks best in my opionion, followed by webp, one thing though, did you use -n to turn off progressive decoding for flif ? If not then it's not really a fair comparison.

Also any chance you could do a comparison at higher file sizes ?

[Jamaika]

did you use -n to turn off progressive decoding for flif ? If not then it's not really a fair comparison.
Also any chance you could do a comparison at higher file sizes ?
I didn't use '-N' because film has the banding, ie. for jpeg. The '-Q' reportedly has a range of 0-100, I used negative values. I think that something is under construction.

Did I use the scan type of progressive or interlace for WebP? It was 'progress' but if I used it for yuv420 or not the result was the same.
I don't know what is the scan type for codec Daala?

The comparison at higher file sizes. I deliberately didn't do this test. I have only a FullHD monitor. It is impossible to evaluate without actual photo size. How to insert pictures 8K / 4K in the forum, not only for two months. Does it make sense if Daala and FliF are incomplete.
It is rather to evaluate what level of development of the codec compression research.

echo Daala image lossless
ffmpeg.exe -loglevel quiet -i "room.png" -s 1920x1080 -r 25000/1000 -an -sn -f yuv4mpegpipe -pix_fmt yuv444p - |
encoder_example.exe --b-frames 0 --keyframe-rate 25 --video-quality 47 --complexity 10 --output "image2_Q47_YUV444_v0.0-1533.ogg" -
echo.
echo BPG image lossless
bpgenc.exe -v -q 41 -e x265 -f 444 -c rgb -b 8 -m 9 room.png -o image2_Q41_RGB_v0.9.6.bpg
echo.
echo FliF image lossless
flif.exe -e -v --lossy=-255 room.png image2_Q-255_RGB_v0.2.0.r13.flif
echo.
echo WebP image lossless
cwebp.exe -v -q 28 -alpha_cleanup -noalpha -progress -m 6 -mt room.png -o image2_Q28_RGB_v0.5.0.webp
echo.

[benwaggoner]

It would be interesting to throw JPEG and a HEVC IDR frame in for comparison. At 25 KB, I think JPEG would really show its age.

[nevcairiel]

It would be interesting to throw JPEG and a HEVC IDR frame in for comparison. At 25 KB, I think JPEG would really show its age.

Isn't BGP practically HEVC IDR?
FWIW, Dalaa looks the best in both images to me, miles ahead too.

[Clare]

Interesting results, Daala looks best in my opionion, followed by webp, one thing though, did you use -n to turn off progressive decoding for flif ? If not then it's not really a fair comparison.

Also any chance you could do a comparison at higher file sizes ?

As far as I tested, FLIF is not performing "well" in lossy mode, i.e. at a constant bpp, it performs worse on SSIM, PSNR-HVS, etc… But it was mainly developped as lossless format, and the developer is selling other feats:
- progressive decoding: you don't need the whole file to get a good idea of the picture.
- no generational loss: if you reencode multiple times the file, it won't get nasty artefacts: https://www.reddit.com/r/programming/comments/4dg2t5/generation_loss_comparison_of_flif_webp_and_jpeg/

[jon]

As far as I tested, FLIF is not performing "well" in lossy mode, i.e. at a constant bpp, it performs worse on SSIM, PSNR-HVS, etc… But it was mainly developped as lossless format, and the developer is selling other feats:
- progressive decoding: you don't need the whole file to get a good idea of the picture.
- no generational loss: if you reencode multiple times the file, it won't get nasty artefacts: https://www.reddit.com/r/programming/comments/4dg2t5/generation_loss_comparison_of_flif_webp_and_jpeg/

Exactly. It's a lossless format, so it's somewhat unfair (though still interesting) to compare it directly to lossy formats. What the lossy FLIF encoder is doing is similar to what pngquant or TruePNG are doing, or recent versions of lossless WebP with the -near_lossless option: it is introducing loss to the image in such a way that it will compress better in the particular target format. The resulting image is still encoded losslessly though: every bit of every pixel is encoded, there's no such thing as quantization or macroblocks which help lossy formats to make low-entropy regions very cheap.

If you compare FLIF to lossy PNG or near-lossless WebP, it is a huge improvement. If you compare it to lossy formats, it's not that great, but on the other hand, those lossy formats have their own problems:
- they only work well on photographs, not on other kinds of images (try using them on diagrams or webcomics)
- generation loss can make the artifacts accumulate
- they sometimes have limitations on the highest quality you can get: e.g. JPEG and WebP use YCbCr which means only ~2^22 different colors (out of the 2^24 colors 8-bit RGB can display, let alone the color depths high-end cameras can capture), and WebP moreover forces 4:2:0 chroma subsampling.

Disclaimer: I'm the author of FLIF. Sorry it took me so long to get here, but this forum is not making it easy for new users to join...

[Clare]

Exactly. It's a lossless format, so it's somewhat unfair (though still interesting) to compare it directly to lossy formats. What the lossy FLIF encoder is doing is similar to what pngquant or TruePNG are doing, or recent versions of lossless WebP with the -near_lossless option: it is introducing loss to the image in such a way that it will compress better in the particular target format. The resulting image is still encoded losslessly though: every bit of every pixel is encoded, there's no such thing as quantization or macroblocks which help lossy formats to make low-entropy regions very cheap.
I understand your pov, but I'm looking at it from an end-user perspective, what interests me is that I download less bytes, on mobile especially. I don't see yet a mechanism which would download partially a file depending on your connection type (3G/4G/Wifi…), for now, the entire file will be downloaded, and FLIF needs more bytes in that case to keep up the quality.
If you compare FLIF to lossy PNG or near-lossless WebP, it is a huge improvement. If you compare it to lossy formats, it's not that great, but on the other hand, those lossy formats have their own problems:
- they only work well on photographs, not on other kinds of images (try using them on diagrams or webcomics)
- generation loss can make the artifacts accumulate
- they sometimes have limitations on the highest quality you can get: e.g. JPEG and WebP use YCbCr which means only ~2^22 different colors (out of the 2^24 colors 8-bit RGB can display, let alone the color depths high-end cameras can capture), and WebP moreover forces 4:2:0 chroma subsampling.

Disclaimer: I'm the author of FLIF. Sorry it took me so long to get here, but this forum is not making it easy for new users to join...

I have yet to verify all those assertions on other file formats. I suppose I will redo my test with screenshots instead of pictures.
Although I'm quite sure WebP use a RGB colorspace when in lossless mode. Just searched and one of the dev says on their forum:
Lossless format works in ARGB mode, at full sampling resolution.

Another problem you need to solve regarding FLIF is computing times, it's the slowest at encoding and decoding of all formats I've tested, and I'm on relatively recent Intel Quadcore. On mobile devices, it would hurt quite a bit. I guess if the bitstream is not finalized you can't really make any asm optimization yet.

For progressive decoding in the browser, maybe this post could give you an idea how to proceed: https://jakearchibald.com/2016/streams-ftw/

[jon]

I understand your pov, but I'm looking at it from an end-user perspective, what interests me is that I download less bytes, on mobile especially. I don't see yet a mechanism which would download partially a file depending on your connection type (3G/4G/Wifi…), for now, the entire file will be downloaded, and FLIF needs more bytes in that case to keep up the quality.

Yes, the partial download thing is something that has to be implemented at the client side (browser). They could do the same thing with progressive JPEG and Adam7 interlaced PNG, by the way. It could be implemented using Range requests (asking only for the first X kb of the file if they're on a slow/expensive connection). I suspect the main reason why browsers aren't doing this already, is because they have no way to know in advance that the JPEG or PNG is progressively encoded (chances are slim with PNG, and with JPEG it depends but non-progressive JPEG is still in the majority IIRC). With FLIF, although it does support non-progressive encoding, it would be reasonable to assume progressive encoding (and do another Range request if that assumption turns out to be wrong).


I have yet to verify all those assertions on other file formats. I suppose I will redo my test with screenshots instead of pictures.
Although I'm quite sure WebP use a RGB colorspace when in lossless mode.

Oh, yes, lossless WebP uses RGB. It is however a completely different image format than lossy WebP. Usually the gap between the lowest quality 'near_lossless' lossless WebP and the highest quality lossy WebP is quite big.


Another problem you need to solve regarding FLIF is computing times, it's the slowest at encoding and decoding of all formats I've tested, and I'm on relatively recent Intel Quadcore. On mobile devices, it would hurt quite a bit. I guess if the bitstream is not finalized you can't really make any asm optimization yet.

For progressive decoding in the browser, maybe this post could give you an idea how to proceed: https://jakearchibald.com/2016/streams-ftw/

Thanks for the link, I'll take a look at it.

Regarding compute times: you can try the option -E10 to reduce the encode effort (the effect on file size should not be too big). A low-level optimized decoder will indeed probably only happen after the format has been finalized.

[Jamaika]

A little about compressing files larger than 4K.
Truthfully it is troublesome for the evaluation on the monitor FullHD. I reduced the size of file BMP 164 times (image 5120x2880). Below are streaks or banding.
For codec AOM/VP8/VP9/VP10 isn't feasible. The file can lessen only 327 times. Below restricts scala Quality level <0-63>.

https://www.sendspace.com/file/4dy4mr

[Marsu42]

As far as I tested, FLIF is not performing "well" in lossy mode, i.e. at a constant bpp, it performs worse on SSIM, PSNR-HVS, etc… But it was mainly developped as lossless format, and the developer is selling other feats

Better "lossy" compression is on the todo-list (http://flif.info/) and there's probab really potential looking at how png preprocessors evolved.

The good lossless mode and built-in lack of generation loss makes this a very nice alternative for image editing and archival esp with > 8bpp which webp doesn't support ... even though it's very unlikely mainstream browsers will pick flif up for internet use as even google's is having a hard time.

Fyi: exiftool now has full flif r/w support for xmp/exif/icc, so that's another step to promote this free and (hopefully) not patented format: http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/FLIF.html

Thanks for the link, I'll take a look at it.

Thanks for all your work and I hope you have enough time to keep improving/finalizing it.

An "official" forum thread would be nice, though, for reqs like this: Please add tiff support, this would it make it easier to use with image editing software like PS or LR that don't output png (and have never heard of pnm and the like).

[smok3]

Some lossless tests, using
flif -E100 in.png out.flif
a. on 5 random CGI (8bpc RGB) wallpapers


png sizes
796K postbang_orig_8bpc.png
1.3M visolje.png
2.0M swirllux.png
2.9M postXp.png
4.3M rex.png
12M total

flif sizes
384K postbang_orig_8bpc.flif
752K visolje.flif
1.5M swirllux.flif
2.0M postXp.flif
2.8M rex.flif
7.4M total

Quite a difference.

p.s. about the flif cli tool: Unexped behaviour with flif *.png < makes an animation of all the pngs and overwrites the first? png.

b. And entire wallpapers folder (mostly 8bpc CGI and CGI with alpha)
69M < png
43M < flif

c. large 16bpc one (13760x5760) with alpha (mandelbulber render)
330M < png
144M < flif
This one took forever.

d. Blender animation, 370 frames at 1920x1080 (16bpc with alpha)
2.2G < png
1.6G < flif # It is slow, this took an hour using gnu parallel (4 running in parallel) on your average i5

[Jamaika]

Version 0.3. Several things:

- fix bug in ColorBuckets+animation, this was a bitstream-breaking bug
- fix bug in unsorted PaletteAlpha (encoder was encoding the palette incorrectly)
- new option --keep-palette; significantly lower memory footprint for 8-bit palette images
- libflif: direct support for palette (UNTESTED, PROBABLY BUGGY!)
- new option --chroma-subsample (produces a truncated 4:2:0 FLIF)

Encoder/Decoder/Viewer FLIF, GCC 7.0 beta 2017, full SDL2.0.5, libPNG 1.7.0 beta 86
https://www.sendspace.com/filegroup/Rwtj5A3EcdJw%2F24pf0%2Fwag

[dipje]

the compression ratio and decoding features (like half res or lossy mode) make it very interesting. But the slllooooww encoding time make it all not worth it to me unfortunately. I compiled 2.2 a few days ago, where do you see a newer version? Last commits on github are from 14th of november as far as I can see.

edit:
D'oh! I was looking at the wrong branch. The master branch has a commit labeling '0.3' but it's not on the official releases yet. Less than 24h ago.

If I'm allowed to share it (don't know actually), I got a Win64 build done with the Visual C++ build tools 2015 (so I guess MSVC 2015 compiler). It's only the encoder/decoder, no viewer or SDL stuff. If there's interest let me know otherwise Jamaika's build will suffice.

[Jamaika]

SDL2.0.5 had a problem. GCC 7.0 doesn't accept xaudio2. Of course, implementations of audio can be cut from the config, but I had left. To happiness need for file include\sal.h.
https://github.com/emscripten-ports/SDL2
https://www.libsdl.org/download-2.0.php
Is there a newer SLD?
https://github.com/spurious/SDL-mirror

Edit: Source master flif/daala/webp + acceptable include GCC 7.0
https://www.sendspace.com/filegroup/jq9Sy9B1hOu7plbxdjUhvmteP39ARTU%2F

Observations:
Fixed the problem WebP of color in the PNG file format (RGB vs BGR).
I am surprised that webp is only 8bit images. Nor does it accept JPEG 16bit, even if we add libjpeg 9.0b.
Viewer FLIF scales the wrong image. Does not display the original size.
Daala has unfinished save the file 'state.c' to import files 10bit.
Daala has an untapped record of doing screenshot in PNG.

Curio. In FFmpeg you can watch lossless JPEG files 16bit based on Adobe DNG.