Slashdot Mirror

← Back to Stories (view on slashdot.org)

FLIF: Free Lossless Image Format

Posted by Soulskill on from the silly-names-for-cool-things dept.

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.

26 of 311 comments (clear)

  1. GPLv3 - the kiss of death by Anonymous Coward · · 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...

    1. Re:GPLv3 - the kiss of death by Anonymous Coward · · 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?

    2. Re:GPLv3 - the kiss of death by Josh+Coalson · · 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.

      --
      FLAC - Free Lossless Audio Codec
    3. Re:GPLv3 - the kiss of death by kthreadd · · 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.

    4. Re:GPLv3 - the kiss of death by thevirtualcat · · Score: 4, 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.

    5. Re:GPLv3 - the kiss of death by morcego · · Score: 4, 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?

      --
      morcego
    6. Re:GPLv3 - the kiss of death by Trailer+Trash · · Score: 4, 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.

      --
      Do you have ESP?
    7. Re:GPLv3 - the kiss of death by kthreadd · · Score: 4, Informative

      Not at all. The goal of free software is that users should have freedom.

    8. Re:GPLv3 - the kiss of death by Kjella · · Score: 3, 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.

      --
      Live today, because you never know what tomorrow brings
    9. Re:GPLv3 - the kiss of death by CastrTroy · · Score: 3, 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.

      --

      Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
    10. Re:GPLv3 - the kiss of death by Dutch+Gun · · Score: 3, 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.

      --
      Irony: Agile development has too much intertia to be abandoned now.
    11. Re:GPLv3 - the kiss of death by TheRaven64 · · Score: 3
      Covering the reference implementation means that no one will even seriously evaluate it. Of the major browsers:
      • Internet explorer (and the new one is called) is proprietary, no GPLv3 code linking allowed.
      • The WebKit underpinnings of Safari are LGPLv2 (not GPLv3 compatible), so even if Apple (which has a corporate policy not to permit GPLv3 code in the door) wanted to adopt it, they can't.
      • Chrome has the same issue with regard to LGPLv2 in WebKit.
      • Firefox is triple licensed, and I think one of the licenses may be GPLv3 compatible, but probably not.

      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.

      --
      I am TheRaven on Soylent News
    12. Re:GPLv3 - the kiss of death by serviscope_minor · · 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...

      --
      SJW n. One who posts facts.
    13. Re: GPLv3 - the kiss of death by kthreadd · · Score: 3, Insightful

      Users that lack the ability to change the software themselves can of course ask someone else to do it for them, either for free or for compensation. This is not at all the case with proprietary software. The vendor may of course choose to change the software for you but you have no such guarantees. Microsoft is not going to make fundamental changes to Windows or most of their other products if you ask them. With free software you are not locked in to the original vendor, you can ask anyone else to do changes for you.

    14. Re:GPLv3 - the kiss of death by ClickOnThis · · Score: 4, 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.

      --
      If it weren't for deadlines, nothing would be late.
    15. Re:GPLv3 - the kiss of death by gstoddart · · Score: 4, 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.

      --
      Lost at C:>. Found at C.
    16. Re:GPLv3 - the kiss of death by Citizen+of+Earth · · Score: 3, Insightful

      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.

      In this case, the conditions mean that this format is DOA, so we can safely ignore it and get on with our lives.

    17. Re: GPLv3 - the kiss of death by Anonymous Coward · · Score: 3, Insightful

      Anytime anyone wants to bring in a new library, the first question is what license is it under. GPL3 means toss it, even for internal projects. There is no GPL3 code in anything I've touched because it's a "legal" virus.

  2. vs TIFF files? by mveloso · · Score: 3, Funny

    How well does it work relative to TIFF files?

    1. Re:vs TIFF files? by QuasiSteve · · Score: 4, 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).

    2. Re:vs TIFF files? by larkost · · Score: 3, 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".

  3. CPU? Memory? by Anonymous Coward · · 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.

  4. Re:Best of all its "Free".... HAHAHAHAH by Rei · · Score: 3, 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.

    --
    Crowd: What do we want? Fry: Fry's dog! Crowd: When do we want it? Fry: Fry's dog!
  5. No real place for it by Solandri · · Score: 4, Interesting
    Unfortunately, I don't really see a killer feature here.
    • Progressive loading (first it loads a low-res lossy version, then additional data sharpens it up, until the final data makes it lossless) was a big deal back in the 1990s when people were on 56 kbps modems and it could take up to a minute for a detailed high-res photo to download. Kodak used a progressive format in their Photo CD standard back when CD readers read data off the CD at standard 154 kbps of audio CDs (in case you ever wondered where the 24x, 52x, etc CD speeds came from). Today, even cell phones have blown past those speeds.
    • A few percent better compression won't matter for the same reason. Bandwidth and storage space are cheap.
    • Universal support for photo-realistic vs. graphic work. Generally people needing those in lossless formats are picky enough to already select exactly which format they're gonna save it in. And again, file size is a much lower priority than compatibility with existing software and printing equipment.

    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.

    1. Re:No real place for it by Anonymous Coward · · 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.

  6. $5 to $15 per GB by tepples · · Score: 4, 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.