Free Lossless Image Format (FLIF)

_wb_

Microbe
Staff member
Joined
Apr 5, 2012
Messages
5,387
Age
38
Location
Brussels, Belgium
... and some more:

Monochrome icons with alpha:



Fractal art:





Wallpapers: (originals were jpegs, so we're encoding some jpeg artifacts here)



The five images in the lossless WebP gallery:



The images in the small Waterloo corpus:



Here is a summary plot of everything, except all those icons (because there so many of them, it would dominate the plot) :



Thanks to Christoph.krn for pointing to test images.

I'm quite excited about these results. It really looks like FLIF can handle a lot of different kinds of images!
 

Binky

Death's Steed
Staff member
Joined
May 28, 2003
Messages
6,913
Location
16A (TO)
I thought he was a wildebeest?

Nevertheless, a wildebeest with some very impressive compsci skills!
 

_wb_

Microbe
Staff member
Joined
Apr 5, 2012
Messages
5,387
Age
38
Location
Brussels, Belgium
Here is a spreadsheet with an overview of all the sets of images I've tried so far:

https://docs.google.com/spreadsheets/d/16ghJEjf_T7TDTOg2WlelnG1SYCsHng6V-1rxdo78YL8/edit?usp=sharing

So far, FLIF is still beating (the hell out of) the other lossless image compression algorithms, whatever I throw at it.

Trying to be modest here, but to me, that is more or less the Holy Grail of image compression: one format that can compress any kind of image well. FLIF is starting to look like a good candidate for that. Now I just need to add animation support, support for 16 bit per channel and HDR, and perhaps some boring things like exif metadata, color profiles etc.
 

Kev2442

Still French
Joined
Nov 4, 2014
Messages
567
Location
42 (Loire) is the answer.
Don't worry, you've gone a long way to the programmer stardom, there ain't much more left ;)

By the way, how does it handle file corruption ? Can we recover a file using the lower-res info ?
 

_wb_

Microbe
Staff member
Joined
Apr 5, 2012
Messages
5,387
Age
38
Location
Brussels, Belgium
Don't worry, you've gone a long way to the programmer stardom, there ain't much more left ;)


By the way, how does it handle file corruption ? Can we recover a file using the lower-res info ?
Corrupted files will be decoded to spectacular glitch art. It's actually quite fun: flip one bit somewhere in the middle of a FLIF file, and you get nice effects.


The FLIF decoder will detect corruption (it checks a checksum). Recovery is not possible, for that you need redundancy, which is the opposite of compression. If the beginning of the file is OK then you can still do a partial (lossy) decode, if you manually set the decode quality, e.g. flif -d -q 50 corrupt.flif output.png
 

Kev2442

Still French
Joined
Nov 4, 2014
Messages
567
Location
42 (Loire) is the answer.
I didn't mean lossless recovery, so it looks like we could still get some of the image back.

I like how JPEG corrupts into large colorless (like in less colors - shades of yellow for example) bands. Do you have any example of glitched FLIFs ?

And the best question of all : are corrupted FLIFs taking less space than corrupted JPEGs and PNGs ? :lol:
 

Magic Sam

Forever Homebrew
Joined
Aug 10, 2007
Messages
2,229
Age
37
Location
Innsmouth, MA
Hi all :)

@ _wb_: any progress on the prior art / patent front ?

If I were you, I'd give it top priority, before FLIF very impressive results start to draw too much attention.

Cheers, Magic Sam
 

_wb_

Microbe
Staff member
Joined
Apr 5, 2012
Messages
5,387
Age
38
Location
Brussels, Belgium
I didn't mean lossless recovery, so it looks like we could still get some of the image back.

I like how JPEG corrupts into large colorless (like in less colors - shades of yellow for example) bands. Do you have any example of glitched FLIFs ?

And the best question of all : are corrupted FLIFs taking less space than corrupted JPEGs and PNGs ? :lol:
Here are some artificially glitched FLIF files.

This is the original image / uncorrupted FLIF file:

orig.png

Here I modified one bit near the beginning of the file:

glitch1.png

One modified bit somewhat further into the file:

glitch2.png

Further again:

glitch3.png

Near the end of the file:

glitch4.png

The above are with FLIF in interlaced mode (the default). In non-interlaced mode, the results are even more 'glitchy':

Beginning of the file:

glitch-ni1.png

Closer to the end:

glitch-ni2.png
 

Klumpen

Run away! Run away!
Joined
Nov 19, 2011
Messages
8,482
Location
Uncanny Valley
Last edited by a moderator:

levi

Still fresh, damnit!
Joined
Oct 6, 2008
Messages
11,950
Location
Somewhere off the coast of the EU
I'm a little perplexed by this paragraph:

"

Even if you use the best available image format (PNG, JPEG 2000, WebP or BPG) depending on the type of image (photograph, line art, etc), then FLIF still beats that by 10% on average!

"

I think the problem is, these prior image formats are no longer the best available, in the vast vast majority of cases it seems.  How about just changing 'best available image format' for 'best pre-existing image format'?

In other news, I cloned your git repo and tried building it.  I get this error:

image/image-png.cpp: In function ‘int image_save_png(const char*, const Image&)’:
image/image-png.cpp:133:37: error: ‘Z_BEST_COMPRESSION’ was not declared in this scope
   png_set_compression_level(png_ptr,Z_BEST_COMPRESSION);

It seems only to be referenced in that one place in your source code, and I've checked the system included png.h and that doesn't define it or anything like it (all its defines seem to begin with PNG_).  In case it is expected to be defined in that file, the version I'm using is libpng version 1.6.18, July 23, 2015.
 
 

_wb_

Microbe
Staff member
Joined
Apr 5, 2012
Messages
5,387
Age
38
Location
Brussels, Belgium
I'm a little perplexed by this paragraph:

"

Even if you use the best available image format (PNG, JPEG 2000, WebP or BPG) depending on the type of image (photograph, line art, etc), then FLIF still beats that by 10% on average!

"

I think the problem is, these prior image formats are no longer the best available, in the vast vast majority of cases it seems.  How about just changing 'best available image format' for 'best pre-existing image format'?

In other news, I cloned your git repo and tried building it.  I get this error:

image/image-png.cpp: In function ‘int image_save_png(const char*, const Image&)’:


image/image-png.cpp:133:37: error: ‘Z_BEST_COMPRESSION’ was not declared in this scope


   png_set_compression_level(png_ptr,Z_BEST_COMPRESSION);
It seems only to be referenced in that one place in your source code, and I've checked the system included png.h and that doesn't define it or anything like it (all its defines seem to begin with PNG_).  In case it is expected to be defined in that file, the version I'm using is libpng version 1.6.18, July 23, 2015.
Both should be fixed now.
 
Top