JBIG2 FLIF PNG
11690 10903 27093 1971_San_Jose_Scale_Scales_on_Branch
10458 9761 23466 1971_San_Jose_Scale_Winged_Adult
44809 44301 105555 Accommodation_ladder
15966 14882 44073 Aconite
27031 25877 59353 Adder
13569 13302 40317 Adenoids
36409 35058 84826 African_elephant
6890 6899 12982 Aft
24465 23170 51297 Agate_A-40
18969 17896 24261 Aisle
8612 8590 23408 Allen_wrench_and_screw
9968 9104 11792 Alpaca
12258 11952 36657 Alternately
196083 192611 254895 Amazon_River
76572 73529 105637 Arabian_Sea
275124 256820 311448 Archery_colored
139482 137329 162432 Argonne_Forest
40681 39952 70999 Astrolabe
24950 23317 32007 Brace
43808 41113 116671 Deer_2My gut feeling says that JBIG2 probably outperforms FLIF on repetitive images (e.g. text), since it specifically detects such patterns. On non-repetitive images, maybe FLIF is better. But it would be nice to have some benchmarks.
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.
There is still a lot of room for improvement in the encoder, which is why (at least for now) it has the LGPL license, to ensure that improvements can be integrated in the reference implementation.
The entire point of LGPL is supposed to be that your corporation provides a binary blob which can be linked against any other such binary blob that supports the requested interface. In this manor someone can use any modified (usually security updates) version of the LGPL library with the rest of your work.
I guess if you require obfuscation or signing of your company's blob things are more difficult. However in that case why aren't you using a security model that signs the code you own and segments out the code you do not?
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...).
See: http://flif.info/example.html
Note that the image in the example was chosen specifically to highlight FLIF's strengths, but the math shows that you could combine the uninterlaced FLIF with the 17KB JPEG 2000 and still take up less space than the interlaced FLIF.
FLIF looks like a very impressive lossless codec indeed, and even is competitive when used as a lossy codec, but the quality of partially downloaded interlaced files just isn't competitive with lossy codecs--including lossy FLIF.
Maybe in some future version of FLIF, with some DCT/DWT-like transform and an option to postpone least significant bits until the end of the bitstream, we can truly get there. But at the moment we're not there yet.
It's still a nice lossless format though :)
[1] https://github.com/FLIF-hub/FLIF-hub.github.io/commit/2b9c81...
The choice of GPLv3 licensing is unfortunate, since it will limit native browser support.
Also, since FFV1 is a video codec, a static image container would need to be defined in order for it to be useful in the same scenarios as FLIF.
FLIF does support a "lossy" encoding method too. The compression FLIF uses (MANIAC Trees) predict what the next pixels will be. If you modify your pixels a small amount so they will be closer to what FLIF expects it will compress much better but still look very similar to the original image. The stored version with the modified pixels would be losslessly stored, in the sense that it perfectly reproduces your image with the modified pixels. But it's lossy in the sense that you had to change the pixels in the first place to better benefit from the way FLIF analyzes and compresses images. The major benefit to this type of lossy compression is that the image doesn't degrade with multiple saves, unlike JPG, where each save compounds the artifacts, causing the "Xerox effect". Here's a video of how FLIF benefits from it's style of lossy encoding:
FLIF is a lossless image format. It's not a good idea to give it an ex-JPEG file as input, just like it's not a good idea to convert JPEG to PNG, because it will need lots of bytes to losslessly compress all those JPEG artifacts that JPEG gets for free :).