Live data from Hacker News

Free Lossless Image Format Publications

flif.info

21–30 of 45 posts

Re: Free Lossless Image Format Publications

#21
post #15

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.

The 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.

Re: Free Lossless Image Format Publications

#22
post #8
post #2

Just a note that the project has undergone fuzzing by author: https://github.com/FLIF-hub/FLIF/issues/57

...though now that I ran fuzzer again, the results are pretty disappointing: https://github.com/FLIF-hub/FLIF/issues/304

I'll fuzz some more :)

Re: Free Lossless Image Format Publications

#23
post #7

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...

The 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.

Re: Free Lossless Image Format Publications

#24

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.

Lepton 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 :).

Re: Free Lossless Image Format Publications

#25

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.pa…

I'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

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.

Re: Free Lossless Image Format Publications

#26
post #13
post #7

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...

It looks like they had a non-alpha release within the last 2 weeks. https://github.com/FLIF-hub/FLIF/releases

On 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)

Re: Free Lossless Image Format Publications

#27
post #18

How 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 [2] https://en.wikipedia.org/wiki/JBIG2

Very 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.

Re: Free Lossless Image Format Publications

#28

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.

So it's lossy if you truncate the file? How does it compare to JPEG on a quality/size basis?

The 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

Re: Free Lossless Image Format Publications

#29

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.pa…

I'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 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 J…

I 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 :)

Re: Free Lossless Image Format Publications

#30

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.pa…

ICIP also included a lossless image compression comparison (though much less detailed than their lossy image comparison) https://people.xiph.org/~tdaede/icip2016_small.pdf
Post reply on HN