Just a note that the project has undergone fuzzing by author: https://github.com/FLIF-hub/FLIF/issues/57
FLIF is pretty neat. I hope it takes off, which it might do as Jon works for Cloudinary.
I assume the news is this recent conference paper: http://flif.info/papers/FLIF_ICIP16.pdf
It will be great when you only need one file for all of your responsive image versions and can just take the part you need. Plug - I wrote about this in my high performance web app book along with other types of compression (https://www.packtpub.com/mapt/book/Application%20Development...).
How does it compare to fax Group 4 compression [1] or JBIG2 [2] for 1bpp -e.g. black and white- images?
The thing about flif that feels good on the old noggin is the fact that you can trade off quality for size just by truncating the file. Imagine a decimal point at the beginning of the file, and your image is a number between 0 and 1. Approximate that number to N digits, and you get an approximation of your image.
Apparently the WIP warning was also removed from the site lately[1]. Can we infer that the format is being finalized?
[1] https://github.com/FLIF-hub/FLIF-hub.github.io/commit/2b9c81...
I'd be curious to see what the result would be if you took the best format for each individual image and added them together; would it be a significant difference over FLIF by itself?
The choice of GPLv3 licensing is unfortunate, since it will limit native browser support.
How does this compare against Dropbox's Lepton? Seems like any of these of image compression formats would make sense to support in archiving software like 7Zip, Winzip, Gzip, etc.
So how is this project even surviving at all considering FFmpeg's FFV1 beats it completely in terms of performance, format support and efficiency?
When trying to promote an open format, LGPLv3 and such reference implementations aren't exactly helping.
You'd want to maximize adoption, and there BSD can help. Adoption of Xiph.org's Vorbis was in good part supported by such a decision.