8 ms·
Free Lossless Image Format Publications
- zylonbane 10y agoSo how is this project even surviving at all considering FFmpeg's FFV1 beats it completely in terms of performance, format support and efficiency?
- 1ris 10y agoIs it? That would be strange because FLIF was developed with FFV1 as a inspiration.
- FlyingAvatar 10y agoDo you have a reference to anyone comparing the formats? 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.
- audunw 10y agoSource? I can't find any comparisons online. FLIF is inspired by FFV1, so how can it be worse?
- mdf 10y agoApparently 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/2b9c8145522cf3eb1a62d260e42152e3bef38deb#diff-eacf331f0ffc35d4b482f1d15a887d3bL127 https://github.com/FLIF-hub/FLIF-hub.github.io/commit/2b9c81...
- avhon1 10y agoIt looks like they had a non-alpha release within the last 2 weeks. https://github.com/FLIF-hub/FLIF/releases https://github.com/FLIF-hub/FLIF/releases
- jaredcheeda 10y agoOn September 19, 2016 Jon Sneyers wrote "I'm going to drop the "rc" and tag what we have now as v0.2. This will be FLIF16 and all bitstream-breaking changes will have to be in a new branch, which will become FLIF17 or FLIF18 or whatever. " (https://gitter.im/FLIF-hub/FLIF?at=57df798133c63ba01a135f0d https://gitter.im/FLIF-hub/FLIF?at=57df798133c63ba01a135f0d)
- jonsneyers 10y agoThe bitstream is kind of finalized as "FLIF16" now, just like GIF87 was finalized in 1987. Future bitstream-changing stuff will go in a new branch, which will eventually become the "FLIF17" or "FLIF18" format (whatever the year will be). Future decoders will decode both FLIF16 and FLIF1x.
- d33 10y agoJust a note that the project has undergone fuzzing by author: https://github.com/FLIF-hub/FLIF/issues/57 https://github.com/FLIF-hub/FLIF/issues/57
- d33 10y ago...though now that I ran fuzzer again, the results are pretty disappointing: https://github.com/FLIF-hub/FLIF/issues/304 https://github.com/FLIF-hub/FLIF/issues/304
- jonsneyers 10y agoI'll fuzz some more :)
- mark-r 10y agoI'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.
- driax 10y agoThe decoder is under the Apache license. But yes otherwise GPLv3+
- vanderZwan 10y agoThat's the encoder, which isn't something browsers would usually bother with. The decoder is Apache licensed.
- mark-r 10y agoThanks, I missed that. Still it means that e.g. Photoshop will never support it, leading to the same conclusion.
- vanderZwan 10y agoWell, IANAL but I think the original creator of FLIF could still decide give a special license to Adobe if they want to negotiate one, no? EDIT: practically confirmed elsewhere in the thread by the original author, with motivation: > 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
- mark-r 10y agoIANAL either, but I suspect it would be between difficult and impossible to offer an alternate license once outside contributions are integrated.
- 10y ago
- jsingleton 10y agoFLIF 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 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/9781785881893/4/ch04lvl1sec24/Compression https://www.packtpub.com/mapt/book/Application%20Development...).
- klodolph 10y agoI'm not convinced that FLIF can really do that. One file for all versions is a nice idea, but in practice, the first 20KB of a progressive FLIF is often an inferior substitute for a 20KB JPEG, to say nothing of BPG. See: http://flif.info/example.html 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.
- jonsneyers 10y agoI agree: if you're fine with lossy, then it's hard to beat lossy formats with a lossless format. 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 :)
- TD-Linux 10y agoICIP also included a lossless image compression comparison (though much less detailed than their lossy image comparison) https://people.xiph.org/~tdaede/icip2016_small.pdf https://people.xiph.org/~tdaede/icip2016_small.pdf
- WhiteOwlLion 10y agoHow 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.
- jonsneyers 10y agoLepton is a recompression format specifically for JPEG. It's lossless in the sense that you can reconstruct the input JPEG perfectly, but of course JPEG is itself an inherently lossy format. 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 :).
- snvzz 10y agoWhen 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.
- noxa 10y agoThe LGPL reference implementation is what has scared off me and many others I know who had an interest in this work. In many corporate environments LGPL is untouchable.
- mjevans 10y agoI really don't understand WHY though; aside from paranoia. 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?
- jonsneyers 10y agoThe decoder is Apache 2.0 licensed. For most applications (e.g. websites, apps, games), you only need the decoder. 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.
- faragon 10y agoHow does it compare to fax Group 4 compression [1] or JBIG2 [2] for 1bpp -e.g. black and white- images? [1] https://en.wikipedia.org/wiki/Group_4_compression https://en.wikipedia.org/wiki/Group_4_compression [2] https://en.wikipedia.org/wiki/JBIG2 https://en.wikipedia.org/wiki/JBIG2
- jonsneyers 10y agoVery good question. Do you or anyone else have a good test set of such images? My 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.
- boramalper 10y ago> Patents for JBIG2 are owned by IBM and Mitsubishi.
- faragon 10y agoI was interested in how they compare in compression terms. Anyway, remaining JBIG2 patents expire in 2019.
- jonsneyers 10y agoHere are some results for a few black & white images from https://commons.wikimedia.org/wiki/Category:PD-ScottForesman https://commons.wikimedia.org/wiki/Category:PD-ScottForesman : (I only compare to JBIG2, not Group 4, since JBIG2 is supposed to be the best of those two) 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_2
- mistercow 10y agoThe 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.
- jandrese 10y agoSo it's lossy if you truncate the file? How does it compare to JPEG on a quality/size basis?
- jaredcheeda 10y agoThe truncated version is basically a lower resolution. So if you have a 5000x5000px image and you display it on your page as 100x100px, it only needs to download a small amount of data to show it at that lower resolution. Obviously being a lower resolution it won't match pixel-for-pixel identically to the original, but if you downloaded the whole file it would. 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: https://www.youtube.com/watch?v=IheZzcYUV9w https://www.youtube.com/watch?v=IheZzcYUV9w
- jandrese 10y agoIs it possible to tell the encoder to do that pixel twiddling or do you have to do it by hand still?