Free Lossless Image Format (FLIF)


... and some more:

Monochrome icons with alpha:

compression-google-material-design-icons.png


Fractal art:

compression-fractal.png


compression-fractal2.png


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

compression-wallpaper-jpegs.png


The five images in the lossless WebP gallery:

compression-webp_gallery.png


The images in the small Waterloo corpus:

compression-Waterloo.png


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

compression-all.png


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!
 
I thought he was a wildebeest?

Nevertheless, a wildebeest with some very impressive compsci skills!
 
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.
 
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 ?
 
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
 
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:
 
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
 
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
 
Last edited by a moderator:
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.
 
 
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.
 
Back
Top