Free Lossless Image Format (FLIF)


ible said:
great!  that would be an excellent addition to your readme ;)

so i have a jpg file about 6.3M, which converts into a png at 14M or ppm at 35M.  the resulting flif is 8.6M.  (PLT fails, ACB fails, if that means anything, and interestingly the output flifs from either ppm or png are identical.  though if i convert the flif back to a png "the binary files [.png's] differ", though i can't see the difference.) 

if i chop up the file as you mention using dd, i start seeing the upper part of the picture at about 2M (the lower half is an impressionistic painting of TV static), at about 4M i get the full picture but with weird colors.  colors are a bit messy even up to 7.9M, though only in the lower half where it looks a bit glitchy.

let me know if the above results are strange (the flif is larger than the original jpg), as i could e-mail you the pic.
Click to expand...
Oh, try refreshing the code, the version you have is probably not doing the interleaving but just scanlines. I'll have to make it into an option to let you pick a method, and interleaving should probably be the default.

Compressing a lossy jpeg file losslessly is not a very good idea, because much of the filesize will be spent on encoding the JPEG artifacts. It will almost always be larger than the lossy jpeg, because obviously the jpeg file is not spending any space on those artifacts. It's a better idea to start from something that is not lossy.

PLT and ACB are two transforms the encoder tries: PLT is palette (if there are less than 512 distinct colors, it generates a palette), and ACB is something palette-like for images with sparse colors (more than 512 but significantly less than 2^24).

PNG files can be different (and have different file sizes) while still encoding the exact same image. If you want to compare two images, you shouldn't use diff, but "compare -metric mepp". If the result is "0 (0, 0)", the images are the same. Output to PPM will be faster, if you don't need alpha.
 
You can static link lgpl libs in closed source software, but you must be able to change the lgpl code and relink the program. This can be done by releasing the prelink object files instead of the code, which creates them.
 
Linux-SWAT said:
I don't know the matter so it may be a bad question, but does it handle raw images ? I have some from a shooting and they are incredibly large.
Click to expand...
Raw camera formats tend to be proprietary and complicated. They contain raw sensor data, which can be quite different from RGB pixels on a square grid.

If you want to handle raw images, it's probably best to use the tools the camera manufacturer provides and generate a PPM or PNG with those tools (not a JPEG because that will be lossy). Sometimes ImageMagick can also do the job (depending on how it was compiled), then you can use "convert input.raw -depth 8 output.ppm" and then compress the ppm using "flif output.ppm compressed.flif".

Note that this will be lossless w.r.t. the output.ppm file, but perhaps the .raw file contained more information: it could have higher color depth, and all kinds of meta-data (exif etc) which would be thrown away by converting it to ppm.
 
Very cool stuff you're working on here _wb_. So far, the results look very promising.

Ziz said:
You can static link lgpl libs in closed source software, but you must be able to change the lgpl code and relink the program. This can be done by releasing the prelink object files instead of the code, which creates them.
Click to expand...
In my experience most commercial companies forbid usage of anything that contains the substring GPL regardless of what the license allows or not. They are just too afraid to use it.
If you want it to be friendly for commercial usage then use something like the Apache 2.0 license.
 
ekianjo said:
Strange that Linux is used by most commercial companies then. It's GPL.
Click to expand...
The underlying OS you use and the applications you develop yourself are quite different. I was mainly referring to library usage.
That said, most companies I encounter tend to use windows, unfortunately.
 
Caine said:
That said, most companies I encounter tend to use windows, unfortunately.
Click to expand...
I'm still trying to get my boss to use the Linux Mint DVD I gave him since he is doing everything in a browser anyway and his Win7 system is horribly slow.

Fear of change is the only reason there, even while everyone in my workshop is a supporter of DRM-free in theory. -.-

Back to topic: I'm really looking forward to the first FLIF video codec. :)
 
Last edited by a moderator:
Yes in general before even considering some open-source software for use in something I work on, the first thing I do is look at the license.  If it's not some form of Apache, Eclipse, or BSD license (i.e,. the 'copy-center' licenses), then I'm most likely not interested.  There's a few others that should be OK (Microsoft Public License comes to mind, MIT License, etc.), but these come up less often. :)

Caine said:
Very cool stuff you're working on here _wb_. So far, the results look very promising.
 

Ziz said:
You can static link lgpl libs in closed source software, but you must be able to change the lgpl code and relink the program. This can be done by releasing the prelink object files instead of the code, which creates them.
Click to expand...
In my experience most commercial companies forbid usage of anything that contains the substring GPL regardless of what the license allows or not. They are just too afraid to use it.

If you want it to be friendly for commercial usage then use something like the Apache 2.0 license.
Click to expand...
 
Last edited by a moderator:
Sorry for being part of it, but perhaps the license discussion should be split?
 
It ultimately doesn't matter what license he uses, the license only applies to the copyright of the code. If I can understand the algorithm I can implement it myself and put whatever license I want on that code, even use it in entirely closed source commercial applications.

This is a good thing!

It means that the discussion about GPL vs LGPL vs whatever will not necessarily hinder adoption. Release the code as pure GPL for all anyone should care, as long as the algorithm is documented any company can implement it in their browser without touching your code. Your GPL code becomes a standard, however, and with multiple people working on it it'll probably be the most efficient implementation, but a company that cares about the licensing and needs to re-implement it themselves probably has the manpower to do so quite decently as well.

To control who uses your algorithm you'd need to patent it.
 
If GPL produces the best results, why should a company do anything differently? What purpose does that serve in terms of dynamically implementing support for an image-format?

The argument started with "in my experience" without any further notice, and "if you want to be friendly" where friendly is arbitrary to the point (not) being made. Then Googer posted a defence that works equally well to support the claim that only male applicants should be hired for a company, which is to say it supported not even itself.

Anyhow, with the code being copy(left)righted. How do you derive the algorithm from within the code without reading the code? Or would that be permitted in GPL /or because only the algorithm is taken away.

Are all the algorithms used documented on their own? Are they novel to the project?
 
Last edited by a moderator:
FLIF is not encumbered by any patents, at least I hope it isn't. It uses arithmetic coding, which has some patent claims but those are all expired. Other than that, it uses only ideas and code by me (and some by my ex-colleague). So it should be patent-free, just the way I want it to be.


In terms of licenses: GPL is all you get for now. I can always add more liberal licenses later. LGPL for a decoding library, or maybe even MIT? We'll see, I'm not in a hurry.
 
Here are some close-ups on the benchmarks I ran. It was quite interesting to see how the other formats have their strengths and weaknesses, while FLIF just beats em all :)

Photographs: (this is what JPEG is good at)

plot-photo.png

Medical images: (a bit like photographs, so still JPEG is good for this)

plot-medical.png

Images with sparse colors: (PNG is good at this)

plot-sparse.png

Geographical maps: (also sparse colors, so PNG is good)

plot-maps.png

Images with transparency: (WebP and BPG are quite good at these)

plot-transp.png
 
JPEG doesn't support alpha channels; in that transparency test, did you do something to simulate storing the transparency data in JPEGs, or are those just stored without a mask?
 
comradekingu said:
How do you derive the algorithm from within the code without reading the code?
Click to expand...
If the algorithm is only documented within the code and there is a serious desire to avoid potential copyright contamination then you simply need two people: one person reads the code and documents the algorithm while the second person takes that document and reimplements it.
 
_wb_ said:
So it should be patent-free, just the way I want it to be.
Click to expand...
Once its done, find some way of "formally" establishing prior-art, just in case some patent troll comes along and throws enough money at their lawyers that you can't fight back.
 
Levi said:
JPEG doesn't support alpha channels; in that transparency test, did you do something to simulate storing the transparency data in JPEGs, or are those just stored without a mask?
Click to expand...
JPEG 2000 does support alpha. JPEG indeed doesn't. The alpha channel was simply dropped when converting to JPEG. So JPEG is really lossy in that last plot ;)

WizardStan said:
_wb_ said:
So it should be patent-free, just the way I want it to be.
Click to expand...
Once its done, find some way of "formally" establishing prior-art, just in case some patent troll comes along and throws enough money at their lawyers that you can't fight back.
Click to expand...
Is putting the code on a public github not enough to establish my prior art?

I'll probably write an academic paper on this and try to get it published, that should also help.
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top