Free Lossless Image Format Publications | Hacker News Reader

Free Lossless Image Format Publications

flif.info

84 pointsmdf43 comments

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

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

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.

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

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

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.

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

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

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.

> Patents for JBIG2 are owned by IBM and Mitsubishi.

I was interested in how they compare in compression terms. Anyway, remaining JBIG2 patents expire in 2019.

Here are some results for a few black & white images from 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

Thank you! It looks amazing. So unless processing speed or memory requirements being a handicap, the FLIF could be a real generic graphics compression candidate :-)

Yes, that's the goal :)

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

Is it possible to tell the encoder to do that pixel twiddling or do you have to do it by hand still?

The encoder option -Q<quality> (that's a capital Q, lowercase -q is used to decode a lower quality preview by only reading part of the file) can be used to do lossy encoding, where -Q100 is lossless and -Q0 is usually the most lossy you would want to go. But you can go lower if you want, using a negative number (e.g. -Q-50); there is not really any lower bound.

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)

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.

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.

The decoder is under the Apache license. But yes otherwise GPLv3+

That's the encoder, which isn't something browsers would usually bother with. The decoder is Apache licensed.

Thanks, I missed that. Still it means that e.g. Photoshop will never support it, leading to the same conclusion.

Well, 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

IANAL either, but I suspect it would be between difficult and impossible to offer an alternate license once outside contributions are integrated.

Good point, I had forgotten about the viral aspect of the GPL. But it looks like Sneyers already thought of that too, luckily.

I'm open to negotiation if Adobe would want to include the FLIF encoder in Photoshop. The other contributors have signed a CLA that allows me to change the licensing to anything more permissive than GPLv3. So if Adobe wants it, they can pay for a non-copyleft license (e.g. Apache 2.0). If that ever happens, I'll be happy to share the licensing fees with the other contributors and donate some of it to the FSF.

Also, Adobe Photoshop (or any other program) is of course free to dynamically link to the libflif library. The LGPL allows that.

Why would they want to pay? Unless the format is widely spread and the fee is much cheaper than implementing their own what interest do they have to pay? I feel it's the opposite now.

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

So how is this project even surviving at all considering FFmpeg's FFV1 beats it completely in terms of performance, format support and efficiency?

Is it? That would be strange because FLIF was developed with FFV1 as a inspiration.

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

Source? I can't find any comparisons online. FLIF is inspired by FFV1, so how can it be worse?

Reply on news.ycombinator.com