comradekingu
Glowing ember
Check out the also belgian http://www.orthanc-server.com/project.
Free Lossless Image Format (FLIF)
- Thread starter _wb_
- Start date
... 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!
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!
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.
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
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 ?
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.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 ?
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
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:
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
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_: 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
Here are some artificially glitched FLIF files.
This is the original image / uncorrupted FLIF file:
Here I modified one bit near the beginning of the file:
One modified bit somewhat further into the file:
Further again:
Near the end of the file:
The above are with FLIF in interlaced mode (the default). In non-interlaced mode, the results are even more 'glitchy':
Beginning of the file:
Closer to the end:
Kev2442
Still French
Awesome ! Interesting to see that interlaced seems more prone to unidentifiable pictures.
WizardStan
Mega GP Mania
- Joined
- May 24, 2008
- Messages
- 16,731
That's some amazing abstract art. You could sell it to a museum
I think you mean the other way round, since the first set is interlaced.
My thought.That's some amazing abstract art. You could sell it to a museum
Especcially this one:
http://boards.openpandora.org/uploads/post-4382-0-66948400-1442227744.png
Last edited by a moderator:
I'm working on a FLIF website. Comments are welcome!
http://people.cs.kuleuven.be/~jon.sneyers/FLIF/
http://people.cs.kuleuven.be/~jon.sneyers/FLIF/
comradekingu
Glowing ember
CK-length pm with revised text sent *
Thanks!
I used some of your suggestions to improve the site.
Anything else I should put on the website?
ptitSeb
Serial Porter
A FLIF file, and the same image in PNG maybe?
levi
Still fresh, damnit!
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:
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.
"
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);
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.
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 am even more impressed. Amazing!