Slashdot Mirror
FLIF: Free Lossless Image Format
nickweller sends a link to an informational post about FLIF, the Free, Lossless Image Format. It claims to outperform PNG, lossless WebP, and other popular formats on any kind of image. "On photographs, PNG performs poorly while WebP, BPG and JPEG 2000 compress well (see plot on the left). On medical images, PNG and WebP perform relatively poorly while BPG and JPEG 2000 work well (see middle plot). On geographical maps, BPG and JPEG 2000 perform (extremely) poorly while while PNG and WebP work well (see plot on the right). In each of these three examples, FLIF performs well — even better than any of the others." FLIF uses progressive decoding to provide fully-formed lossy images from partial downloads in bandwidth-constrained situations. Best of all, FLIF is free software, released under the GNU GPLv3.
Using GPLv3 will all but ensure no corporate/enterprise support, thus leaving the older, less useful formats in place.
Not necessarily. If the format is free and well-defined, there can be other implementations. This happened with FLAC, which started out LGPL.
FLAC - Free Lossless Audio Codec
Note that in the case of Vorbis Stallman actually endorsed the BSD license because he understood that there was no other path to wider adoption. FLIF is the same - it'll remain nothing but a little-known oddity unless they decide to use a BSD license that will allow Microsoft, Opera, Firefox, Chrome, and Safari to use the code.
Do you have ESP?
That question is nearly un-answerable. TIFF isn't a concrete format like PNG or JPEG, rather it is a more meta-format that can contain tiled chunks of other formats. Even that isn't quite a good description as is over-generalizes. But it does capture the basic essence. TIFF is frighteningly complex, with lots of corner cases, and in most cases is only appropriate for very large images (for the tiling), or special cases such as scientific/biological data where the raw data is embedded in the "image".
It occurred to me that there might be a way around this problem: give it a header that starts with a PNG signature and then stores the FLIF data in one or more chunks that have no effect (such as text chunks or a new non-registered chunk type), then moves on to chunk(s) representing the exact same image in a conventional PNG format. So a person whose browser has no FLIF support will just read it as a PNG file that's about 50% larger than it needs to be, while a person whose browser has FLIF support can give up downloading the file as soon as it receives the FLIF chunk and not bother downloading the PNG version.
Crowd: What do we want? Fry: Fry's dog! Crowd: When do we want it? Fry: Fry's dog!
NASA might be interested in it for transmitting data back from its deep space probes (New Horizons is gonna take a year to transmit back all the pictures it took). Likewise, someone might implement it as a way to reduce bandwidth when browsing the web over expensive satellite data connections while at sea. Those are the only use cases I can think of where low bandwidth still matters.
Do you know the value of a "free" platform nobody can integrate into their own product without their product becoming GPL, and whose reference implementation can't be used?
Not a damned thing.
So people can use it, but they need to write their own. They can't reference the reference implementation without tainting their own.
So, what exactly is the incentive to give a damn about the format?
Because I'm reading this as "look at our super awesome new format ... want a lick? Psyche!".
So, something already GPLd will integrate this. And pretty much everyone else will wonder what they can do with it.
Lost at C:>. Found at C.