
Free Lossless Image Format Publications - mdf
http://flif.info/publications.html
======
snvzz
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.

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

~~~
mjevans
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?

------
d33
Just 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
...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
I'll fuzz some more :)

------
jsingleton
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](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...](https://www.packtpub.com/mapt/book/Application%20Development/9781785881893/4/ch04lvl1sec24/Compression)).

~~~
klodolph
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](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
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 :)

------
faragon
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](https://en.wikipedia.org/wiki/Group_4_compression)

[2] [https://en.wikipedia.org/wiki/JBIG2](https://en.wikipedia.org/wiki/JBIG2)

~~~
jonsneyers
Here 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

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

~~~
jonsneyers
Yes, that's the goal :)

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

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

~~~
jaredcheeda
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](https://www.youtube.com/watch?v=IheZzcYUV9w)

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

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

------
mdf
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...](https://github.com/FLIF-hub/FLIF-
hub.github.io/commit/2b9c8145522cf3eb1a62d260e42152e3bef38deb#diff-
eacf331f0ffc35d4b482f1d15a887d3bL127)

~~~
avhon1
It 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
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](https://gitter.im/FLIF-
hub/FLIF?at=57df798133c63ba01a135f0d))

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

~~~
vanderZwan
That's the _encoder_ , which isn't something browsers would usually bother
with. The _decoder_ is Apache licensed.

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

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

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

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

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

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

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

