FLIF: Free Lossless Image Format 311
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.
GPLv3 - the kiss of death (Score:4, Insightful)
Using GPLv3 will all but ensure no corporate/enterprise support, thus leaving the older, less useful formats in place.
Sometimes zealots get in their own way...
Re: (Score:3, Insightful)
Yeah, doesn't this require that all software that supports the format needs to be released as GPLv3 as well?
Who's bright idea was that?
Re:GPLv3 - the kiss of death (Score:5, Informative)
Yeah, doesn't this require that all software that supports the format needs to be released as GPLv3 as well?
Who's bright idea was that?
The reference implementation is under GPLv3. Everyone is of course still free to create their own implementation and license it under whichever license they want.
Re:GPLv3 - the kiss of death (Score:5, Insightful)
Yeah, doesn't this require that all software that supports the format needs to be released as GPLv3 as well?
Who's bright idea was that?
The reference implementation is under GPLv3. Everyone is of course still free to create their own implementation and license it under whichever license they want.
Isn't that exactly the kind of thing that free software was supposed to avoid? Having to reinvent the wheel because some nitwit had it locked on copyright?
Re:GPLv3 - the kiss of death (Score:5, Informative)
Re:GPLv3 - the kiss of death (Score:4, Insightful)
The GPL says nothing about users of the software. It only has restrictions as far as how the source must be handled when distributing the software. If you're just using the software, there's nothing in the GPL that has any effect on you. If you make modifications to the source code, and want to distribute those modifications (as compiled binaries or as source code) then you need to start adhering to the GPL. This means it doesn't really apply to most users, because most of them lack the skills necessary to make any modifications to the source code. The best they could do is pay somebody else to make the modifications they need.
Re: GPLv3 - the kiss of death (Score:2)
Re: (Score:3)
Users are free because they have access to the source code, have the freedom to learn from it, change it and/or pass it along.
You mean the freedom to pay someone else to do it, as was suggested above in this Post [slashdot.org] . Sounds like a lot of Proprietary packages to me.
Re: GPLv3 - the kiss of death (Score:4, Insightful)
Re: (Score:2)
That doesn't require GPL3. GPL2, BSD, MPL... lots of OSS licenses exist with the same abilities for users. Obviously GPL3's purpose must be more than that.
It is. The main difference between the GPL and other licenses is that GPL does not let anyone take away freedoms provided by the GPL. For example, one cannot hide modifications to GPL code, or stop someone from modifying GPL code on which a program depends.
Re: (Score:3)
Re: (Score:3)
GPL is anti-developer
Nope. I'm a developer and quite often think the GPL is the best solution. It helps if you're a developer and user of the program.
Re: (Score:2)
> and GPL is anti-developer
That's complete nonsense.
GPL prevents other developers from hijacking the freedom to lock everyone OUT
The goal is FREEDOM for FOR ALL.
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
Well, this means no users will be using the software because Microsoft will not be able to bundle it in Windows as a native format (not without releasing the source code of Windows).
This is the part where the GPL becomes problematic - while I think releasing the software that relates to the open source project is perfectly agreeable, making it apply to every other bit of software its linked to is not.
Re: (Score:2)
Not at all. The goal of free software is that users should have freedom.
You haven't read The Cathedral and the Bazaar, have you?
Re: (Score:2)
Re: (Score:2)
As usual, the GNU GPL does not restrict what people do in software; it just stops them from restricting others.
Re: (Score:3)
Re: (Score:2, Insightful)
Great, so it was just announced and it already needs to be re-engineered independently or the implementation forked and re-released to be usable for most.
This is why we can't have nice things.
Re: (Score:2, Informative)
Re:GPLv3 - the kiss of death (Score:5, Insightful)
Great, so it was just announced and it already needs to be re-engineered independently
You're getting it for free, with conditions. Conditions that you (or someone else) can work around. If you don't like the conditions, go create your own format.
This is why we can't have nice things.
Freedom is a nice thing, and the GPL gives it to you, provided you don't prevent others from enjoying the same freedom you get from the GPL.
Re:GPLv3 - the kiss of death (Score:4, Insightful)
In this case, the conditions mean that this format is DOA, so we can safely ignore it and get on with our lives.
Re: (Score:2)
You must understand that the GPL does for share your definition of freedom. Being able to further restrict the ones you pass the software on to is not freedom, it's tyranny.
Here's my vote for Slashdot to include a new mod category: "-1 uses the word 'tyranny'".
Re:GPLv3 - the kiss of death (Score:4, Insightful)
The reference implementation is under GPLv3. Everyone is of course still free to create their own implementation and license it under whichever license they want.
And any time the reference implementation changes you have to alter your implementation in a non-copyright infringing way. That is a lot harder than it sounds because any time you get a little bit lazy and copy-paste, literally or practically your implementation is now legally fishy. Creating the clean room implementation and paper trail proving you've actually come up with your code independently is actually a lot worse when there is available source code than when it's not. Did you see how much shit Oracle managed to stir up over a few Java interface definitions and trivial bits of code? No company with a sane legal department is going to touch this with a ten foot pole.
format change vs reference implementation change (Score:3)
No, reference implementation changes do not mean all implementations have to change. Only format changes mean all implementations have to change.
Re: (Score:3)
The GPL does not prevent you from learning from the source code to implement a compatible version under a different license.
No, but "derived from" extends further than implementing the exact same thing with different variable names that you typed up yourself. It's the same for all copyrighted material, you don't need direct quotes to infringe on a book, the exact samples to infringe on a song's melody or using cutouts to infringe on a photograph. It's not a patent, it doesn't get a monopoly on every implementation. But you have to show it's not the same implementation, because that will infringe copyright.
Re: (Score:2)
The GPL neither permits it nor forbids it. So it then falls back to the question of whether or not your "reimplementation" is legally a "derivative work" of the original implementation.
AIUI (i am not a lawyer) if you read some code and then write very similar code that can be considered to be "copying" even if you didn't write it out word for word. If you try and reimplement a complex format you are very likely to end up writing very similar code to the original imlementation simply because there is only on
Re: (Score:2)
Then that block of code would be functional, rather than creative, and it wouldn't be covered by copyright (if the courts agree with you, assuming it comes to that)
IANAL, YMMV
Re: (Score:2)
Oracle v. Google (Score:2)
The GPL does not prevent you from learning from the source code to implement a compatible version under a different license.
That depends on the outcome of the forthcoming fair use defense phase of Oracle v. Google.
Re: (Score:2)
The GPL says what the GPL authors wrote.
But the GPL means what a judge says it means.
What Oracle does is up to Oracle.
And up to what a judge will let Oracle do.
Re:GPLv3 - the kiss of death (Score:4, Insightful)
The reference implementation is under GPLv3. Everyone is of course still free to create their own implementation and license it under whichever license they want.
Which, I'm betting, no one will care to do. Even when there is a permissive license, it's still incredibly difficult for a new file format to gain any traction. Think about how many years it took for PNG to take root with decent support in graphics tools and browsers.
If the ultimate goal is to promote this file format, this is not the best way of doing it. Apparently, keeping the software they wrote as FOSS/GPL is more important to the authors than broad adoption. That's fine, but just don't expect the rest of the world to come rushing to adopt this format. Sadly, it's probably going to be ignored, even if it's technically superior to PNG as claimed.
Re: (Score:3)
At which point, as a developer, I'll go "So where's the demand?"
This is a new "supposedly better" file format. But no one supports it yet, so you want me to waste my time creating an implementation for it?
Effectively, a chicken and egg situation - no one wants to implement it if they don't have to because the license isn't usable and no one's using
Re: (Score:2)
How many good christian family members have you lost to the GPL?
I'm pastafarian, you insensitive clod.
Re: (Score:3, Insightful)
Using GPLv3 will all but ensure no corporate/enterprise support, thus leaving the older, less useful formats in place.
Sometimes zealots get in their own way...
Yeah, I was just about to say this. Why in God's name would one put a library like this in v3? I suppose I should be happy they made a library at all instead of just "creating an app", but this will be nothing more than a science project.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
It looks like the Xpdf web page is inconsistent. I got this from the README [foolabs.com]:
License & Distribution
Xpdf is licensed under the GNU General Pulbic License (GPL), version 2
or 3. This means that you can distribute derivatives of Xpdf under
any of the following:
- GPL v2 only
- GPL v3 only
- GPL v2 or v3
The Xpdf source package includes the text of both GPL versions:
COPYING for GPL v2, COPYING3 for GPL v3.
Please note that Xpdf is NOT licensed under "any later version" of the
GPL, as I have no idea what those versions will look like.
If you are redistributing unmodified copies of Xpdf (or any of the
Xpdf tools) in binary form, you need to include all of the
documentation: README, man pages (or help files), COPYING, and
COPYING3.
If you want to incorporate the Xpdf source code into another program
(or create a modified version of Xpdf), and you are distributing that
program, you have two options: release your program under the GPL (v2
and/or v3), or purchase a commercial Xpdf source license.
If you're interested in commercial licensing, please see the Glyph &
Cog web site:
http://www.glyphandcog.com/ [glyphandcog.com]
Re:GPLv3 - the kiss of death (Score:5, Interesting)
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.
Re: (Score:2)
Re: (Score:2)
FLIF will never kill PNG anyway as long as it keeps linking to libpng.
Re:GPLv3 - the kiss of death (Score:5, Informative)
That was my initial thought too, but unless I'm mistaken, the GPLv3 just covers the reference implementation.
The fact that the format itself is completely patent and royalty free means that anyone can implement their own version under whatever license they choose. They just can't use the reference implementation.
Re:GPLv3 - the kiss of death (Score:4)
If you can't ship a beta of the browser that supports it, then how do you do things like compare things like page loading time, bandwidth usage, and so on? Doing an open source release under a license that says 'you can't use this code, and if you want to implement this spec then you'd better make sure that you didn't look at our code' strikes me as taking the piss.
Re: (Score:3)
Covering the reference implementation means that no one will even seriously evaluate it. Of the major browsers:
All of this is irrelevant once someone releases a non-GPL library that supports the format. And internal evaluations can be done with the GPL implementation, while an adopter waits for (or develops independently) a non-GPL implementation.
If you can't ship a beta of the browser that supports it, then how do you do things like compare things like page loading time, bandwidth usage, and so on? Doing an open source release under a license that says 'you can't use this code, and if you want to implement this spec then you'd better make sure that you didn't look at our code' strikes me as taking the piss.
Nothing is stopping you from looking at the GPL code to see how it works, and then writing your own implementation. You just can't copy-paste the code verbatim.
Re: (Score:2)
Well, copyright law.
Re: (Score:2)
Well, copyright law.
Copyright law covers the expression of an idea, not the idea itself.
Re: (Score:2)
A codec incorporates not only coding techniques but what a 0 represents in each circumstance and what a 1 represents. By the logic of the opinion of the United States Court of Appeals for the Federal Circuit in Oracle v. Google, the particular senses for bitstream elements chosen in FLIF would be the expression of the general idea of a lossless still image codec incorporating particular techniques. The question of whether copying these senses is fair use has been remanded to the United States District Court
Re: (Score:2)
Yeah, I know that. Reading the documentation of the idea and creating a codec is fine. Reading the code and creating new code could, if the code is similar enough, be copyright infringement.
Re: (Score:2)
You use the reference implementation internally for initial testing, and if you like it you code your own to release in your browser. I expect the Chrome and Firefox guys wouldn't have too much trouble coding their own image decoder module. Or someone can write up their own and release it GPLv2 or BSD or whatever.
Re:GPLv3 - the kiss of death (Score:5, Interesting)
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.
Re:GPLv3 - the kiss of death (Score:5, Interesting)
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.
Re:GPLv3 - the kiss of death (Score:5, Informative)
Note that in the case of Vorbis Stallman actually endorsed the BSD license
It's actually part of their general policy. For implementing things like reference implementations of unencumbered protocols and file formats, they recommend a permissive license to aid adoption:
http://www.gnu.org/licenses/li... [gnu.org]
Does FLIF "provide specialized facilities"? (Score:2)
From the paragraph on that page recommending a permissive license: "Some libraries implement free standards that are competing against restricted standards". Against which restricted standard for lossless image coding is FLIF competing?
If none, then it goes on to state: For libraries that provide specialized facilities, and which do not face entrenched noncopylefted or nonfree competition, we recommend using the plain GNU GPL." So the question is one of whether FLIF "provide[s] specialized facilities".
Re: (Score:2)
Using GPLv3 will all but ensure no corporate/enterprise support, thus leaving the older, less useful formats in place.
Sometimes zealots get in their own way...
You beat me to it. I was coming here to post exactly that.
Re: (Score:3)
vs TIFF files? (Score:4, Funny)
How well does it work relative to TIFF files?
Re: (Score:2)
"Well" in what sense? TIFF's just a container.
Re: (Score:3)
How well does it work relative to TIFF files?
Exactly the same: just use TIFFTAG_COMPRESSION with the value COMPRESSION_FLIF.
Facetious of course, but TIFF is more of an archive format which is somewhat good at storing image data, than an actual image file format. Less facetiously still, TIFF allows you to specify horizontal differencing and deflate compression which makes it quite similar to PNG. PNG has 4 modes: horizontal, vertical, square and none. So, you can get TIFF to be about as good as PNG without
Re: (Score:3)
Well, if you refer to the final size for lossless encoding, remember that TIFF image data can be compressed using various algorithms [wikipedia.org] and the format can be extended, so your mileage may vary. Nonetheless, just for this aspect, it should compare better than the usual TIFF containing LZW compressed data, though (but I'm not sure this is still the most common lossless compression scheme being used for TIFF).
Plus, it behaves nicely on incremental decoding (less b
Re:vs TIFF files? (Score:5, Insightful)
In lossless compression, it beats TIFF hands-down for the mainstream compression methods (packbits, LZW, ZIP). You can use pretty much whatever compression you want in a TIFF file (it's more of a container format than an encoding definition), but given how well FLIF compresses vs other image compression methods, it's pretty good.
The progressive loading is also superior to TIFF, which generally don't use progressive at all. I'm not sure how much this matters, though, as their example of using it for responsive design assumes that the graphic at lower resolutions 'as is' gives an acceptable enough result to replace current solutions that serve a different resolution image that may well have been specifically tuned for a given resolution/bandwidth. JPG already has similar progressive loading, and I don't know of any browser that will halt a JPG download after the Nth iteration deeming it 'good enough'.
It also apparently has animation support, which may be better than APNG and MNG and others. For now GIF still seems to rule the animated image domain, despite its many shortcomings (imgur's faked-out video -> gif -> mp4-served-via-html-named-gifv doesn't count).
On most other fronts, though, it seems TIFF (and other formats) may be superior. A rather big one is that it doesn't yet support metadata. Another big one for the graphics industry would be lack of CMYk and other color spaces.
It also seems to support 'only' 16 bits per channel. There's a variety of 32bpc encodings for TIFF (straight, LogLUV, etc) and I do hope that it's just an arbitrary limit such that the work done in FLIF could conceivably be added to formats like OpenEXR.
That would also largely take care of concerns like the lack of additional channels, layers, etc. that can be presented in TIFF. This would make OpenEXR the container format and FLIF the encoding (or, at least, the compression).
That would still place it squarely in the interest of those dealing with graphics (a very fast decode of the progressive version used when framescrubbing, then loading the full 10k plate when paused for a bit, for example), and not so much the average consumer.
For consumer adoption, it would need broad support among browsers (lack of webp support means that hasn't particularly taken off), from digital imaging device manufacturers (you're more likely to upload 'a FLIF file' if that's what rolled out of the camera / got written to the SD card to begin with) and in common software (but that tends to follow from the other two).
Re:vs TIFF files? (Score:4, Interesting)
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".
What's wrong with GPLv3? (Score:3)
Re: (Score:3)
Rule of thumb. If your license requires a lawyer to review it, it's not free.
Re: (Score:2)
Re: (Score:2)
Great. (Score:3, Insightful)
Now all we need to do is get image-makers to distribute in a format no-one can view, and software-writers to include support for a format that no-one ever encounters.
Re: (Score:2)
One wonders how anyone ever established any image format in the first place.
And how it performs with existing libraries (Score:2)
Thousands of existing software libraries support existing image formats. None of them support this new wonder format. There are perfectly usable 10+ yrs tools that work fine with image manipulation, creation, viewing, etc. that need no updates.
CPU? Memory? (Score:5, Insightful)
How much CPU time does it take to compress vs the others?
How much memory does it need to compress vs the others?
How much CPU and memory does it take to decompress vs the others?
Hard to say it's better without a complete picture.
Re: (Score:2)
Re: (Score:3)
Been to the cinema lately? You're watching a stream of JPEG2000 images at 24, 25 or more frames per second.
JPEG2000 isn't dead, and if it couldn't be decoded quickly enough, it wouldn't be used for DCPs.
No real place for it (Score:5, Interesting)
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.
Re:No real place for it (Score:5, Insightful)
You're out of touch with half of the world. Bandwidth is extremely expensive and unreliable. The most popular browser in India simply doesn't load images, unless you explicitly click on them. Efficient progressive image formats would be great in those markets.
And if you told Google you could use half or less of the storage space for all images all of a sudden of course they would take you up on it. Storage is cheap, but definitely not free.
$5 to $15 per GB (Score:5, Insightful)
Bandwidth and storage space are cheap.
Bandwidth is not cheap. Cellular and satellite Internet tend to cost $5 to $15 per GB.
Nor is storage space cheap, especially with the premium for a 64 GB phone over a 16 GB one. Also servers, as Anonymous Coward mentioned in #50646339.
Re: (Score:3)
I still like Adobe DNG (Score:2)
Digital Negative was originated by an Evil Corporation(TM), but Adobe insists that they want to keep the format open and IP-free. It has been submitted to ISO a s a standard, basically TIFF with room for the rich metadata that photographers crave: https://en.wikipedia.org/wiki/... [wikipedia.org]
I will give up my DNG when you pry the cold dead platters of my drawerful of external backup from around it.
The most important question: (Score:3)
Is it pronounced with a short or long i?
This Again? (Score:2)
Re: (Score:2)
That effort was borked by the Second-System Effect [catb.org] among the PNG developers. All they needed was a simple way to replace the animated-GIF functionality. It seems that WebM will be the replacement for animated GIFs, decades later.
Great marketing (Score:3)
I like how the web site insists that the format is a work in progress, and future versions may not actually load images created with the current implementation.
Unlike document formats, media formats rarely evolve over time. For a media format not to be production ready means it's currently worthless. Be prepared to wait a few years to use a format that will never be widely adopted. Nice.
Multi Image Lossless Format (Score:3)
A colleague nailed this: (Score:2)
Use it and never be able to sell your product. Or use it and get fired for being an idiot. Hurrah!
Almost 30 years ago a colleague of mine used a phrase, referring to the pre-L GPL licensing terms, that succinctly described this kine of "free":
"More expensive than money."
Re:Best of all its "Free".... HAHAHAHAH (Score:4, Interesting)
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.
Re: (Score:2)
Why would anyone do that instead of using HTTP Accept headers?
Re: (Score:2)
But what makes users choose a paid distro? (Score:2)
Unless you're basing a business model on distributing to people with Internet connections not suited for gigabyte transfers, such as dial-up, ISDN, satellite, or cellular, what will make users choose your distribution for a fee over someone else's distribution without charge?
Re: (Score:2)
Re: (Score:2)
What part of "released under the GNU GPLv3" didn't you understand?
Re: (Score:2)
It's a lossless format, so the resulting image is the same pixel for pixel with the original.
Progressive lossless codecs are also lossy (Score:2)
Did you even read the title of the article?
It's a lossless format
It's designed to be "progressive". This means the prefix of any lossless file is a lossy file. In fact, the more graceful degradation of truncated progressive FLIF compared to truncated progressive PNG is touted as an advantage over PNG.
Re: (Score:2)
Um... https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:2)
Makes me want to think, really, are new standards really necessary?
Also, JPEG2000 is dead and buried and I'm using PNG for photography editing. It goes without saying that if you can process the raw file from the camera, you can also use PNG to save it/resize it and then export it to JPEG for web or other formats as required for printing.
Re: (Score:2)
Implicit in "Obligatory xkcd #927" comments is "I do not think this proposed standard will cause at least two standards to cease competing." What about FLIF keeps it from displacing the existing standards?
Re: (Score:2)
I think they meant game and application screenshots as images to compress, since that's going to be quite a big chunk of the use cases.
NEF to FLIF (Score:2)
Nikon cameras produce raw images in NEF format. Couldn't you just patch your NEF to PNG converter to support NEF to FLIF as well?
FLIF allows arbitrary zoom (Score:2)
It supports setting the zoom level through its progressive encoding: a prefix of the lossless FLIF bitstream can be interpreted as a low-res FLIF. As for pan, a set of FLIFs in an array (as with the "Click and Drag" xkcd comic or any Internet mapping program) could fix that.
Re: (Score:2)