FLIF: The Newest Free Software Image Format For Smaller Web Images

[phoronix]

Phoronix: FLIF: The Newest Free Software Image Format For Smaller Web Images

FLIF is short for the Free Lossless Image Format and is the newest open-source (GPLv3) attempt at being a better image for the web than JPEG, PNG, WebP, etc...

http://www.phoronix.com/scan.php?page=news_item&px=FLIF-Announced

[xeekei]

Great to see progression in the lossless image format space.

[Nille]

I don't see a reason to use this. Its GPLv3 and not usable in other Software. Maybe as LGPL but not this way.

[Henning]

I would guess that the reference implementation is GPLv3... someone else could implement the algorithm in LGPL or BSD licence.

[plonoma]

An universally usable fully-featured image file format is a dream come true.
At long last we will be able to encode images with many sharp edges and images without many sharp edges, mostly blurry edges (photographic images) in one file format that can encode them all!

How does FLIF stack up against PGF (Progressive Graphics File)?
PGF is quite an interesting graphics file format with an interesting set of capabilities.

https://en.wikipedia.org/wiki/Progressive_Graphics_File

http://www.libpgf.org/index.php

I see FLIF has Multiple resolution representation as described in http://flif.info/responsive.php
But has it Region Of Interest extraction too?
From PGF (Progressive Graphics File)'s wikipedia page:

• ROI extraction: Since version 5, PGF supports extraction of regions of interest (ROI) without decoding the whole image.

FLIF's FLIF and responsive web design page ( http://flif.info/responsive.php ) mentions zoom, is ROI extraction basically what they mention with the following line in the Client side knows best section?

• zooming, screen rotation, window resizing;

And FLIF should get two different file extensions, MIME types. One for lossless and one for lossy.
(Example for a nice set of extensions/MIME type name: .FLIFL and .FLIFY, a .FLIF can be lossy or lossless.)

[Mr. Octus]

More info about the project can be found here:
https://boards.openpandora.org/topic...e-format-flif/

He seems aware about the GPLv3 "issue" and says he plans on keeping it that way while he improves the core code, the lib version (libflif) will probably be LGPL.

One of the first issue on GH is about the license

https://github.com/jonsneyers/FLIF/issues/3

https://github.com/jonsneyers/FLIF/issues/9

He is also taking advice on spreading the word:

Now, how do I make sure that FLIF conquers the world and becomes a new standard image format, used all over the interwebs? This is quite an ambitious goal, right? So your suggestions are extremely welcome!

https://boards.openpandora.org/topic...comment-403003

A few users have also suggest the idea of using flif as a video codec, would love to see more news about the project on Phoronix (Michael <3)

[Luke_Wolf]

I would guess that the reference implementation is GPLv3... someone else could implement the algorithm in LGPL or BSD licence.

Well... unless they published the spec, no you can't actually, because in order to reimplement it either you would need to black box reverse engineer what's going on, or you would need to look at the source code. If you looked at the source code then if you do up your own implementation you will have created a "derivative work" which then itself must be under GPL v3. If you're stuck reverse engineering it, then the code might as well have been proprietary in the first place.

[Szzz]

Well... unless they published the spec, no you can't actually, because in order to reimplement it either you would need to black box reverse engineer what's going on, or you would need to look at the source code. If you looked at the source code then if you do up your own implementation you will have created a "derivative work" which then itself must be under GPL v3. If you're stuck reverse engineering it, then the code might as well have been proprietary in the first place.

So every implementation is derivative of the spec and everyone who will read the spec can only write implementation with the compatible license. Wine, for example, is a derivative of the MSDN documentation, which AFAIK is not published under open source license, so Wine cannot be LGPL licensed. I think you are saying some nonsense.

[SystemCrasher]

Cool, etc. But if creator of this thing really cares about format adoption, he is wrong about sooooo many things...

1) I come to their site. And what I can see? "Contact your ISP abuse department"? Very welcoming! No, I do not have virus. And haven't attempted to hack 'em. This stupid site just scared of some Tor exit node. And if someone can't configure their simple and totally STATIC web site to withstand arbitrary traffic (so they do not need to resort to such idiocy), they're hardly experts in web, to begin with. I would take their mumblings on how it can improve web with a grain of salt...

2) Okay, worked it around and so, I got github link... but wait, it is not library, right? Gif and JPG took their places under sun since they were first of their kind. Zlib and libpng were convenient and under very liberal license. This sparked formats adoption in areas where PNG works better (aka static lossless images). Competitors mostly stuck, even if they had some advantages due to numerous reasons. One of which is lack of adequate libs...

3) And even if it was lib, GPLv3 is cool... but not for libs, dammit. It have to be at least LGPL and preferrably "v2 or later". So ppl can hook lib to their programs and rock-n-roll.

4) But wait, isn't it C++? So, good luck to hook it to most programs. And forget about different language bindings.

5) Isn't CABAC a most heavily patented feature of H.264? Like most of arith coding techniques. Is their changed version of algo safe against patent sharks? Web fell into this pit. Twice. First time with patented LZW in gif. Then there were patent claims on JPG. And only PNG has been relatively clean.

The result? Even browsers would be unable to hook this code up. And one have to be really naive if they expect browser devs are experts in image coding and would be happy to re-code something similar to CABAC to suit their needs on their own. Especially when there are no formal specs and only some C++ code you can't realistically use for anything but doing few compression experiments.

So, idea is cool, but actual implementation... I'll be damn surprised if it would take off as replacement of something.

[Nobu]

So every implementation is derivative of the spec and everyone who will read the spec can only write implementation with the compatible license. Wine, for example, is a derivative of the MSDN documentation, which AFAIK is not published under open source license, so Wine cannot be LGPL licensed. I think you are saying some nonsense.

code != specification
The spec (if it exists) could be permissively/BSD-like licensed, and if the code is based on that spec, could remain licensed as such. If the spec is based on the code, then would it have to be GPL licensed? Dunno, but if the author of the code is also the author of the spec he can license it how he likes. Multiple authors complicate things, of course.