23 ms·

Free Lossless Image Format

1254 points by davidbarker 11y ago

MasterScrat 11y ago
Sounds almost too good to be true... any major downside, other than current lack of support?
- sprash 11y ago
  FTA: "FLIF is a work in progress. The format is not finalized yet. Any small or large change in the algorithm will most likely mean that FLIF files encoded with an older version will no longer be correctly decoded by a newer version. Keep this in mind."
- fsiefken 11y ago
  Perhaps the MANIAC/CABAC decoding or encoding is computationally more intensive compared to the others? Concerning lack of support, just like with the BPG decoder you could generate the Javascript through Emscripten so any javaszcript enabled browser can view them. Personally an even more efficient lossy image compressor would be great (getting my avatar down to 1K and still sharp). When using diagrams or text the mozjpeg artifact eraser is adequate.
- raving-richard 11y ago
  Because it is GPL3, it won't be supported by Google on Android, by Apple probably anywhere, or by Microsoft anywhere. In other words, it's a lovely idea, but due to a poor choice of license, it won't get any adoption. C.f. Ogg Vorbis, where the license for the specification is public domain, and the license for the libraries are BSD-like. To quote FSF: Some libraries implement free standards that are competing against restricted standards, such as Ogg Vorbis (which competes against MP3 audio) and WebM (which competes against MPEG-4 video). For these projects, widespread use of the code is vital for advancing the cause of free software, and does more good than a copyleft on the project's code would do.[1] I would suggest that this is a case where widespread use is more important than copyleft. [1]　https://www.gnu.org/licenses/license-recommendations.html https://www.gnu.org/licenses/license-recommendations.html
  - aaronharnly 11y ago
    Agree – using GPL rather than LGPL or BSD in the reference implementation will prevent this from being widely adopted. UPDATE: See lt's helpful comment above.
    - davexunit 11y ago
      So, the free world can use this library and the proprietary world will have to develop their own if they want to use the format. Proprietary software developers get to piggy back off of tons of free software, and then when someone decides that they don't want to enable that for their particular program/library, people complain about it. It makes no sense.
      - brianwawok 11y ago
        I think license depends on your goal. If your goal is to create a web image format.. you need all the browsers to agree to include you. All browsers will not add a GPLv3 image type. Therefore it is dead before it launched.
        davexunit 11y ago
        The author has expressed interest in dual-licensing, so there will probably still be options. GPLv3+ or LGPLv3+ sounds reasonable.
        snuxoll 11y ago
        LGPLv3 will still prevent use of Windows Phone, iOS and Android.
        davexunit 11y ago
        No, that's backwards. Microsoft and Apple and Google prevent the usage of the GPL/LGPL. Don't blame the GPL for the bad behavior of large corporations that are using their immense power to try to stop copyleft.
T3RMINATED 11y ago
Request denied by WatchGuard HTTP Proxy. Reason: Category 'Newly Registered Websites'
- fnordfnordfnord 11y ago
  WatchGuard is a disease. They also listed Hackaday as banned for "Hacking". Ever try to get a site unlisted from them? It's nearly impossible, and may only last a month or so before it goes back on the blacklist.
StavrosK 11y ago
How does this unicorn achieve all this, and unencumbered by patents on top of everything else?
- fnordfnordfnord 11y ago
  A million monkeys, scratching their heads, looking for a better way to save/send their photo albums. Progress has been on order for a while now, someone(s) is/was bound to crack it sooner or later.
- Daemon404 11y ago
  I cannot imagine it truly is - it uses a variation of CABAC, which sure has patents related to it. I wonder if they had a real legal person OK that claim.
lt 11y ago
This is really interesting! There seems to be some additional technical information here: https://boards.openpandora.org/topic/18485-free-lossless-image-format-flif/ https://boards.openpandora.org/topic/18485-free-lossless-ima... - for interlacing it uses a generalization of PNG's Adam7; unlike PNG, the geometry of the 2D interlacing is exploited heavily to get better pixel estimation, which means the overhead of interlacing is small (vs simple scanline encoding, which has the benefit of locality so usually compresses better) - the colorspace is a lossless simplified variant of YIQ, alpha and Y channel are encoded first, chroma channels later - the real innovation is in the way the contexts are defined for the arithmetic coding: during encoding, a decision tree is constructed (a description of which is encoded in the compressed stream) which is a way to dynamically adapt the CABAC contexts to the specific encoded image. We have called this method "MANIAC", which is a backronym for "Meta-Adaptive Near-zero Integer Arithmetic Coding".
- versteegen 11y ago
  Great, thanks. It seems there is no technical description available anywhere beyond what you quoted. They haven't written it up, and I couldn't even find comments in the source providing details. That's too bad, but he (I assume that's Jon Sneyers) does say he hopes to write it up later. Also, comments in that thread on speed [1]: In terms of encode/decode speed: both are slow and not very optimized at the moment (no assembler code etc, just C++ code). A median file took 3 seconds to encode (1 second for a p25 file, 6 seconds for a p75 file), which is slower than most other algorithms: WebP took slightly less than a second for a median file (0.5s for p25, 2s for p75), PNG and JPEG2000 took about half a second. It's not that bad though: BPG took 9 seconds on a median file (2.5s for p25, 25s for p75), and brute-force pngcrushing took something like 15 seconds on a median file (6s for p25, over 30s for p75), so at least it's already better than that. Decode speed to restore the full lossless image and write it as a png is not so good: about 0.75s for a median file, 0.25s for a p25 file, 1.5s for a p75 file. That's roughly 3 to 5 times slower than the other algorithms. However, decoding a partial (lossy) file is much faster than decoding everything, so in a progressive decoding scenario, the difference would not be huge. [1]: https://boards.openpandora.org/topic/18485-free-lossless-image-format-flif/?page=2#comment-399001 https://boards.openpandora.org/topic/18485-free-lossless-ima...
deleted 11y ago
[deleted]
baldfat 11y ago
I don't see any foundations or corporations backing this project. Without support (I hope something like this does gain wide scale support (SVG in browsers for the Internet please already!) I don't see this being accepted.
- pmelendez 11y ago
  What you say it's true for a wide scale usage. However, imagine a small company, startup, or a sole developer using this for their projects or as a internal format. I found it very interesting even if there is not a widespread use of it.
  - baldfat 11y ago
    It is interesting! I agree but I guess I am getting to old. I keep hearing awesome new formats and than they just waste away. The few success stories are few and in between. FLAC and OGG are a good example. OGG is a decent format and I prefer it to MP3 but it really just withered. FLAC is awesome but it is far from main stream. Heck even SVG is far from where it SHOULD be.
    - anc84 11y ago
      And then there is Opus which took the world in storm.
      - baldfat 11y ago
        It has the devices covered > Devices based on Google's Android platform, as of version 5.0 "Lollipop", support the Opus codecs. Chromecast supports Opus decoding. Grandstream GXV3240 and GXV3275 video IP phones support Opus audio both for encoding and decoding. Developers were Mozilla and Skype (MS after the purchase) >Its main developers are Jean-Marc Valin (Xiph.Org, Octasic, Mozilla Corporation), Koen Vos (Skype), and Timothy B. Terriberry (Xiph.Org, Mozilla Corporation). Among others, Juin-Hwey (Raymond) Chen (Broadcom), Gregory Maxwell (Xiph.Org, Wikimedia), and Christopher Montgomery (Xiph.Org) were also involved. Standardized > https://tools.ietf.org/html/rfc6716 https://tools.ietf.org/html/rfc6716 Still I think most people have no idea about Opus as a codex and only thing OGG (Container which Opus uses) and Vorbis codec format (Which Opus was to replace).
fnordfnordfnord 11y ago
Where are the images to compare? Bellard has a very neat demonstration on his page http://xooyoozoo.github.io/yolo-octo-bugfixes/#nymph&jpg=s&bpg=s http://xooyoozoo.github.io/yolo-octo-bugfixes/#nymph&jpg=s&b... BTW, credit to the flif people for linking competitor formats bpg and webP
- adrianN 11y ago
  It's lossless. They look just like the originals.
  - fnordfnordfnord 11y ago
    Thanks. I had a derp moment. I guess I wasn't prepared to believe that "lossless" really meant lossless.
- kcorbitt 11y ago
  Well given that they're all lossless formats, the image should appear identical with any of the codecs, with only the file size (and encoding style) being different. More practically, since browsers won't have an flif decoder there isn't an easy way to embed the images online without reencoding them in a different format, which would rather defeat the purpose of putting up sample images.
  - fnordfnordfnord 11y ago
    Oh! Derp! I guess I am used to marketing-level abuses of language. >More practically, since browsers won't have an flif decoder there isn't an easy way to embed the images online without reencoding them in a different format, which would rather defeat the purpose of putting up sample images. Did you follow the link I posted? I think Bellard put together a pretty nifty demo. Note: Bellard credits xiph.org as the originator of the demo page. http://people.xiph.org/~xiphmont/demo/daala/update1-tool2b.shtml http://people.xiph.org/~xiphmont/demo/daala/update1-tool2b.s...
  - espadrine 11y ago
    They could demonstrate interlacing comparisons by slowing down (through setTimeout()) the image processing in the browser. Having a Youtube video already shows that it works really amazingly well (especially coming from Adam7), but seeing it interactively on a selection of images would be nice. After all, the single biggest feature is that you can actually stop downloading the image whenever you feel like you don't want to spend more bandwidth!
chmike 11y ago
I couldn't see any information on speed performances. There is certainly a price to pay for these impressive results. It could be the compression time. I hope not the uncompressing time.
- pmelendez 11y ago
  I am not relating to this project, but I am actually in the middle of the development of a 3d image retrieval server and this very interesting to my work right now. I will compare this using lodepng as a baseline and hope to report soon.
- foldor 11y ago
  I'm guessing that they're not releasing the numbers on that yet until the format is finalized. It's likely not gone through any serious optimizations yet.
  - versteegen 11y ago
    See the quote I pulled out above: https://news.ycombinator.com/item?id=10318161 https://news.ycombinator.com/item?id=10318161
paxcoder 11y ago
I want to believe.
rwinn 11y ago
Wow! Higher compression than any other format, full transparency support, progressive/partial loading AND animations?! I can't wait for this to get widespread adoption! Github repo here btw: https://github.com/jonsneyers/FLIF https://github.com/jonsneyers/FLIF
- digi_owl 11y ago
  GPLv3 will be a hard sell...
  - lucian1900 11y ago
    In fact, it makes it impossible to use in practice. None of the major browsers are GPLv3.
    - zanny 11y ago
      The GPL is compatible with BSD, MPL, and MIT licenses that Firefox / Chromium use. The problem is more that Firefox / Chrome ship proprietary bits like the DRM modules that would violate the linking GPL coverage of flif. And that Chrome is proprietary. Its going to need to be relicensed LGPL to be included.
      - snuxoll 11y ago
        > The GPL is compatible with BSD, MPL, and MIT licenses that Firefox / Chromium use. Yes, it is compatible, the other way around. You can take BSD, MPL, MIT code and adopt it into a GPL project, not the other way around. EDIT: Even LGPL won't work here as it will prevent use on Windows Phone, iOS and Android.
        Someone 11y ago
        If Apple's attributions are correct (1), there is LGPL software on iOS, for example libiconv, and even GPL software (libgcc, libstdc++), but those have linking exceptions. WebKit also is partially LGPL. Possibly not coincidental, the latest LGPL version I could find in the 'legal' section is 2.1. (1) they may be overly cautious, given that they mention the L4 kernel, lua, and Tiny Scheme.
onion2k 11y ago
The 'only download as much of the file as you need' way of managing detail levels is brilliant.
- kcorbitt 11y ago
  Totally. I really recommend watching the video under the "Progressive and lossless" heading. With just 20% of the file downloaded the image quality was already subjectively quite good. I didn't even know progressive loading within a single file was a thing, but it's a neat trick.
  - talmand 11y ago
    Isn't a progressive jpeg loaded from a single file? Or are you referring to a different context of progressive with this file type?
  - linkydinkandyou 11y ago
    It's been a thing for at least 20 years, when "wavelet" compression first started being used. https://en.wikipedia.org/wiki/JPEG_2000#Progressive_transmission_by_pixel_and_resolution_accuracy https://en.wikipedia.org/wiki/JPEG_2000#Progressive_transmis... And the Digital Cinema formats widely used today rely on this so a 2K or 4K stream can be extracted from the same file. What's "new" about FLIF is the better lossless compression rate
iraphael 11y ago
This is really interesting. One of the most interesting parts is the progressive decoding/responsive images. http://flif.info/example.php http://flif.info/example.php (go to the bottom of the page). Basically, the last example shows that, if you want a scaled version of the image, you can simply stop decompressing. No need for multiple image files. Just create one with very high quality and decompress until you get the quality you want and scale it down with html. edit: more info on the responsive side of FLIF: http://flif.info/responsive.php http://flif.info/responsive.php
- digi_owl 11y ago
  Makes me think of the web of old, where sometimes an image would load in multiple passes.
  - michaelmior 11y ago
    I assume you're talking about progressive JPEGs. These are still fairly common in my experience. It's just that with today's typical connection speed, you'll rarely notice.
    - masklinn 11y ago
      There's also progressive PNGs. Progressive JPEGs have the advantage that they increase compression ratio (though they're more expensive to decode, as you need multiple passes and refresh)
      - darkmighty 11y ago
        They increase compression ratio? That's counter-intuitive. You're effectively imposing an ordering requiring certain information to be available first, so you'd expect the compression be at most as good as non-progressive. I guess the changed ordering makes the statistics simpler and easier to compress, or something like that.
        11y ago
Navarr 11y ago
Obligatory XKCD: https://xkcd.com/927/ https://xkcd.com/927/ No but I'm excited, this is progress!
alphabetam 11y ago
GPL 3. Meaning it won't ever be adopted by anyone.
- yiyus 11y ago
  IANAL, but I guess the file format itself is not covered by the GPL 3, only the reference implementation. They specifically say that "FLIF is completely royalty-free and it is not encumbered by software patents". So, I suppose people will be allowed to develop their own libraries with another license.
  - nstart 11y ago
    They also go on to say. That might be a clear indication that this is in fact GPL v3. FLIF is Free Software. It is released under the GNU General Public License (GPL) version 3 or any later version. That means you get the “four freedoms”: The freedom to run the program, for any purpose. The freedom to study how the program works, and adapt it to your needs. The freedom to redistribute copies. The freedom to improve the program, and release your improvements to the public, so that the whole community benefits.
  - dagw 11y ago
    True, but the only complete documentation of the file format I found was the source code of the reference implementation. So the only way to write a new implementation is to study the reference implementation, which will make your new implementation "tainted".
    - antientropic 11y ago
      Studying GPL'ed source code does not "taint" anything. You're absolutely allowed to do that. If you're really concerned about subconsciously copying elements of the original into your implementation, you could let somebody else study the original and write a spec.
      - nickpsecurity 11y ago
jttam 11y ago
Does it use a middle out algorithm? :)
- anandvc 11y ago
  That's exactly what I was wondering! :)
hokkos 11y ago
It would be nice to have a comparison with https://en.wikipedia.org/wiki/JPEG_XR https://en.wikipedia.org/wiki/JPEG_XR
espadrine 11y ago
The most solid feature is lossless responsiveness. Stopping the download gives you a lower-resolution image. When scaled, the image then becomes lossy. Here is a thorough analysis of how good that lossy image is: http://flif.info/example.php http://flif.info/example.php It shows how very good lossy BPG is, but also how good FLIF is against anything but BPG (and against lossless BPG).
emergentcypher 11y ago
Why all the hate for GPLv3?
- josteink 11y ago
  Sharing code is no longer cool if people have to share back. Or at least so it seems. The GPL-hate in here really is quite immense, even though time and time again, RMS has been shown to be right about his stance on freedom. Should we attribute it to people's desire for a quick ("free") fix over long term considerations? It's hard to tell, but I suspect the silicon valley influence here doesn't help. There everyone wants to take everyone else's hard work and code, build a weekend SaaS and get rich. The GPL, while not preventing that, is clearly in opposition to that goal.
  - versteegen 11y ago
    As someone who made a negative comment about the GPL elsewhere in this thread, I think I'll comment. I have absolutely nothing against the GPL, and use it myself. However, using the GPL for a library seems like a bad idea, because there are a lot of people, especially at companies, which won't touch the GPL. So if you license a library GPL and it's useful someone is just going to come along and reimplement it with a more liberal license. And such a waste of resources is sad to contemplate. The ideal of the GPL was that it would force other projects to switch to GPL, but it doesn't seem to happen too much in practice because the modern world has an abundance of alternative software for any task. Think long term: chances are someone in the next 50 years will be annoyed enough to reimplement whatever you're doing.
    - robert_foss 11y ago
      In the context of this project which is yet to have a finalized specification I think the GPL is an ideal format. As a project it is important to have access to all of the pieces and avoiding incompatible forks of different kinds in the early stages. So for the purpose of developing a 'golden standard' prototype for FLIF, I don't think a non-GPL license would have served them better. The author seems to have the same idea, and is considering re-licensing to MIT later on. I don't agree with corporate apologeticism which seems to be the norm here. If a company wants get something for free, expecting it to publish source code changes is not an actually high threshold. It might be in terms of corporate politics, but in actuality it is not hard.
donlzx 11y ago
I hope the idea of progressive downloading partials can be applied to other files types as well. For example, if commonly used libraries such as minified Javascript source files are encoded and distributed incrementally, we don't have to repetitively download various versions of the same library from different CDNs for different websites, which will save a huge amount of Web traffic.
russnewcomer 11y ago
I don't see any comparison here on the impact of decompressing? Is this going to hit a processor harder than JPG/PNG/BPG/et al will, and thus be a hit to people on mobile devices?
- infogulch 11y ago
  Decompression speed is important. (And more important than compression speed.) But the bottleneck on mobile devices is increasingly falling on the mobile network. CPU performance per watt is falling dramatically where mobile bandwidth per watt is staying relatively static. If this continues eventually we'll get to the point where the power usage (e.g. for loading and displaying a web page) is completely dominated by data transfer, and more and more computationally expensive compression becomes the best way to save overall power by trading cheap cpu cycles for expensive bandwidth.
- logfromblammo 11y ago
  Processor and storage are much cheaper than network bandwidth this year. The most relevant tradeoff calculation now would probably be bandwidth versus battery power consumption. The FLIF image decoding library might want to be battery-aware, such that it can automatically scale back the power consumption at lower battery charge levels, in a user-configurable fashion. Or perhaps it caches a fully decompressed or partially decompressed file to storage, so that it only does the battery-devouring steps once.
hknd 11y ago
Is this Pied Piper?
tempodox 11y ago
Those diagrams are incomprehensible. The sorted and unordered WTF-per-diagram rate is too frigging high.
robert_foss 11y ago
An interesting aspect that has not been mentioned on flif.info nor here, is the implementability on silicon. How many transistors would be needed for and encoder? How about a decoder or a codec (encoder/decoder)? And what about clock speed? How long is the longest pipeline in the codec? For any other modern codec the hardware aspect is a very important one. Usecases like smartphone browsers or smartwatches are very common, and on platforms like that performance==battery life==usefulness.
deleted 11y ago
[deleted]
- lt 11y ago
  This is lossless, not lossy. The output is the same.
  - deleted 11y ago
    [deleted]
- Steuard 11y ago
  "Free Lossless Image Format": the quality metric for lossless images is "identical pixel by pixel to the reference format". (There's obviously a question about how to judge quality for a given partial download of a FLIF file, but for the total file there really isn't any question of quality metrics at all.)
tfinniga 11y ago
This is an exciting development. I think the concerns about the licensing are a bit premature - honestly, this is currently a research project, not a practical replacement for existing image formats. The licensing is only one of several impediments to adoption. - The format has no spec - The format may change, rendering all previous images unreadable - The format has no javascript implementation, and no way of running on old browsers. - As far as I can tell, there hasn't been a patent search done to see if it violates other patents from other organizations. For example, this one: http://www.google.com/patents/US7982641 http://www.google.com/patents/US7982641 - No peer-reviewed paper published yet? However that doesn't mean that we can't recognize the accomplishment - this looks like a very promising research result, and I hope the project continues! Good work Jon!
- mmastrac 11y ago
  > - No peer-reviewed paper published yet? While there's no paper there's a full Github repo which I'd actually say is quite impressive.
  - joshvm 11y ago
    As someone who regularly has to read supposedly landmark papers - with no source code provided - this is far preferable in my opinion. Computer vision is terrible for this!
- lcswi 11y ago
  Screw software patents!
edubart 11y ago
I see you there Pied Piper, but will it still perform well on 3d?
ruffyen 11y ago
I think the important thing that needs to be addressed here before this file format takes hold is how the hell you are going to pronounce this format. I don't want another gif/gif debate.
antirez 11y ago
One would expect, in theory, Google to push this like mad, based on what they did with HTTP 2.0 in another part of the stack, for possibly less gain at the cost of much more complexity and standards shaking. Let's hope it really happens.
gok 11y ago
Comparing compression ratios without comparing compute/memory requirements is...not terribly meaningful.
shmerl 11y ago
> FLIF is completely royalty-free and it is not encumbered by software patents. That's good but does it actually avoid patent minefields that others scattered around? That's equally critical for healthy adoption.
boksiora 11y ago
looks great!!! i want to see it in my browser and websites, home some browser support come from chrome and firefox
happywolf 11y ago
Would like to point out a caveat listed in that page, as follows. Don't convert all your photos in your drive (yet). "WARNING: FLIF is a work in progress. The format is not finalized yet. Any small or large change in the algorithm will most likely mean that FLIF files encoded with an older version will no longer be correctly decoded by a newer version. Keep this in mind. "
natch 11y ago
One more nice feature they didn't mention: unambiguous pronunciation.
- mdup 11y ago
  So, is it eff-leef or fleef ?
  - tricolon 11y ago
    /'flɪf/
kenOfYugen 11y ago
"A FLIF image can be loaded in different ‘variations’ from the same source file, by loading the file only partially. This makes it a very appropriate file format for responsive web design. " Awesome! I have been toying with custom png 'container' ideas in the past offering similar 'responsive' features (i.e various resolutions, lossy-lossless versions) I would like to see the ASM.js version of the decoder and see how that one performs.
cfv 11y ago
GPL for me is a dealbreaker. Can't use it unless I'm able to link to it without having my client relinquish his rights to his stuff.
proyb2 11y ago
Between Brotli and FLIF, which is good enough?
- gillianseed 11y ago
  Brotli is excellent at text and does a great job at compressing overall, but FLIF is written directly to excel at lossless image compression, hence FLIF will be much better unless it's a really poor solution (which results show it's certainly not). Likewise Brotli will not beat FLAC at compressing audio, since FLAC is specifically written to do that.
  - robryk 11y ago
    Actually, FLAC doesn't have a very good compression ratio (e.g. see [1]). It does have features that are very important for audio streams: it can be quickly resynced and AFAIK decompression proceeds at nearly-constant speed. [1] https://news.ycombinator.com/item?id=7893171 https://news.ycombinator.com/item?id=7893171
    - gillianseed 11y ago
      Even so, I would be very surprised if FLAC did not outperform general purpose compressors if the test is done on a wider range of music than a single piano piece (which should be very compressable overall as audio goes). edit: went and did a test on a couple of tracks, using brotli: bro --quality 11 --window 24 against flac -8 (best settings in both cases) satie - gymnopedie no 1: wav: 41.6mb brotli: 28.1mb flac: 14.7mb ram jam - black betty: wav: 41.8 brotli: 35.8 flac: 26.5 vangelis - tao of love: wav: 29.4 brotli: 23.0 flac: 13.4 meat load - paradise by the dashboard light: wav: 89.3 brotli: 78.3 flac: 58.5 certainly not a massive test, and there are likely general purpose compressors which does a better job than brotli, still I feel rather convinced that they will not do better than FLAC other than in extreme cases such as the piano piece you linked to.
joelthelion 11y ago
How cpu-intensive is it? Decompression speed can be an issue, especially on mobile.
- matheweis 11y ago
  Here is what he says about that: https://boards.openpandora.org/topic/18485-free-lossless-image-format-flif/?do=findComment&comment=399001 https://boards.openpandora.org/topic/18485-free-lossless-ima... Decode speed to restore the full lossless image and write it as a png is not so good: about 0.75s for a median file, 0.25s for a p25 file, 1.5s for a p75 file. That's roughly 3 to 5 times slower than the other algorithms. However, decoding a partial (lossy) file is much faster than decoding everything, so in a progressive decoding scenario, the difference would not be huge. There's still room for optimizing the encode/decode speed, but it's not very useful to do that before the bitstream is somewhat finalized. The prototype implementation I have now is not extremely fast, but at least it's in the right ballpark. Most likely even an optimized decoder will still be slower than an optimized PNG decoder, but the difference will be small enough to not matter much (certainly compared to the time won by downloading less bytes). comradekingu likes this
spullara 11y ago
One of the least interesting parts of this is that it is GPL. Someone should reimplement it with a BSD license so it can be used more widely. AFAIK & IANAL, but I don't think you could integrate this with FF, Chrome, Safari or IE.
- jblow 11y ago
  No kidding. If you want an image format to become widely adopted and standardized, GPLing the code is a pretty bad idea.
  - Aldo_MX 11y ago
    Not just an image format, everything you want to become widely adopted and standardized should refrain from using the GPL, even the FSF[1] recommends using the Apache License in this specific case. Some libraries implement free standards that are competing against restricted standards, such as Ogg Vorbis (which competes against MP3 audio) and WebM (which competes against MPEG-4 video). For these projects, widespread use of the code is vital for advancing the cause of free software, and does more good than a copyleft on the project's code would do. In these special situations, we recommend the Apache License 2.0. [1] https://www.gnu.org/licenses/license-recommendations.html https://www.gnu.org/licenses/license-recommendations.html
    - bloody_pretzels 11y ago
      Note that the Apache License isn't compatible with GPLv2. If you don't make use of any patents use BSD/MIT/ISC instead. Sadly there isn't a real alternative permissive license with a patent clause. There is a license called COIL[1], but it hasn't seen much adoption yet. [1] http://coil.apotheon.org/ http://coil.apotheon.org/
      - Aldo_MX 11y ago
        Nothing that a dual license GPL/APL wouldn't solve.
  - 11y ago
whatever_dude 11y ago
Sounds amazing. But: no information on encoding time. I'm assuming it's going to be a beast. Which, IMO, is totally fine.
rancur 11y ago
BMP is free isn't it????
- rancur 11y ago
  I guess trollers/jokesters aren't appreciated here...
shaikharbaz 11y ago
I imagine images appearing as fast as I can scroll, with enough visual clue to them to find images way way more quickly than with thumbnails today. As a start, thumbnails could use <a href="http://www.hookad.com">post</a> http://www.hookad.com">post</a>
williamsharkey 11y ago
Can the progressive data obscure previous portions of the image? If so, it can also be a hacky video format. EG: A flif would specify how many megabytes it used per second. There would not be discrete "frames". If a video flif said that it used 1MB per Second, and you wanted to see what the video looked like at 10.8 seconds, you would download 10.8MB .
yekim 11y ago
Pretty sweet. Will be interesting to see where this lib goes. If someone has some time, maybe they could give it a mention on the Wikipedia page: https://en.wikipedia.org/wiki/Image_file_formats https://en.wikipedia.org/wiki/Image_file_formats
dnesteruk 11y ago
Doesn't the GPL license generally ruin being able to use this in a commercial product by having to provide source code and affecting derivative works, too?
andrepd 11y ago
I wonder how it compares to lossy (but high-quality) compression codecs.
jonsneyers 11y ago
To clarify: at the moment FLIF is licensed under the GPL v3+. Once the format is finalized, the next logical step would be to make a library version of it, which will be most probably get licensed under the LGPL v3+, or maybe something even more permissive. There is not much point in doing that when the format is not yet stable. It's not because FLIF is GPL v3+ now, that we can't add more permissive licenses later. And of course I'm planning to describe the algorithms and the exact file format in a detailed and public specification, which should be accurate enough to allow anyone to write their own FLIF implementation.
- bhouston 11y ago
  Very neat stuff. Would be nice to support 16/32bit floating point for true HDR as well if can be easily accommodated.
  - jonsneyers 11y ago
    Can be done. Basically just change the type of ColorVal and implement a float variant of writer() and reader() in maniac/symbol.h.
    - alanh 11y ago
      I want to chime in to say that the lack of a common image format (and displays, for that matter) with true support for high-range photos is really holding back digital photography in my humble opinion.
      - Tloewald 11y ago
        Nah, it's the camera makers that are holding things back by sticking to proprietary formats and in some cases obfuscating them. There's OpenEXR, HDR, and DNG (the last of which is a true RAW format). The big issue with creating a true interchange format is that RAW files don't have proper color information for all pixels (they instead have red, green, or blue data for any given pixel, sometimes deliberately blurred, etc.) and interpolating the values to produce reasonably nice faux color for each pixel is actually very hard and the algorithms the different companies use is presumably protected by patents.
cbr 11y ago
They claim this is good for responsive images: The download or file read operations can be stopped as soon as sufficient detail is available, and if needed, it can be resumed when for whatever reason more detail is needed. -- http://flif.info/responsive.php Unfortunately that's not how HTTP works. Your browser opens several connections to a website, and makes requests for resources. Each connection is in use until that resource is fully loaded, at which point you can send a request for another resource up that connection. Yes, the browser could close the connection after it has received enough of the image for the desired quality, but there's a lot of overhead in setting up a new connection, including some round trips, and so that is probably a net loss. The JPEG image format also supports progressive images, in browsers today, and no one has figured out how to use that for single-file responsive images yet. (You might be able to do something in HTTP/2 where you set the priority of the stream to 0 after you have enough of it for your needs, but I don't think anyone has gotten this working yet.)
- XCSme 11y ago
  Why do you say it is a net loss? Maybe the server could signal the end of file based on some request parameters (the resolution of the image).
  - AshleysBrain 11y ago
    Yes, handling it on the server side sounds like a reasonable workaround. For example photo.flif?res=1x returns Content-Length: 100000, and photo.flif?res=2x returns Content-Length: 200000, with both returning data from the same file.
  - cbr 11y ago
    I say net loss because with current http the loss of closing the connection is typically much higher than the loss of downloading more bytes than you need. Connection reestablishment needs a lot of round trips.
- szym 11y ago
  Could use range requests (RFC 7233), albeit with some overhead.
arasmussen 11y ago
How does it compare to slightly lossy jpegs?
jaigouk 11y ago
wow. this is amazing!
URSpider94 11y ago
I don't see how the author can claim that FLIF is "unencumbered by software patents," only that he/she hasn't obtained patents on the work already. This has traditionally been one of the problem with so-called "free" image formats -- it's not that the standards body or creator asserts patent rights, it's that other inventors claim that their pre-existing patents cover the new format.
jmspring 11y ago
Ignoring patents is a concern. The patent issue is a major one and not lightly ignored. I haven't checked patent status, but one of the things that was pretty contentious with JPEG 2000 during the ISO standardization process was patents around arithmetic coding -- not just the method for doing the encoding, but also things like context based modeling. In reality, the majority of image compression comes about in the "modeling" stage -- be it predictive coding, context based encoding coefficients, etc. I'm happy to see new advances in image coding, but having spent many years working with Glen Langdon and others, the depth of IP concerns is still fairly fresh in my memory.
tracker1 11y ago
GPLv3 will make adoption problematic... if it were at least LGPL so that it could be used as a library that would make adoption far more likely.
waynecochran 11y ago
BE SKEPTICAL! Not a single mention of "signal to noise ratio" (SNR). If you are going to list compression rates you have to give the associated quality -- SNR is used in the literature. I was suckered into "fractal image compression" by those selling the snake oil back in the 90's -- I am far more skeptical about these things now.
- GhotiFish 11y ago
  could you go into detail about what you mean with "associated quality"? These are lossless compression algorithms that are being compared here. The only other pertinent details regarding a lossless compression algorithm are the Compression Ratio, CPU usage, and Memory usage.
  - waynecochran 11y ago
    Because I am an idiot. Disregard. Move along.
hellcatv 11y ago
How does this compare to packpnm http://packjpg.encode.ru/?page_id=73 http://packjpg.encode.ru/?page_id=73
hngiszmo 11y ago
For all the GPL-hate in this thread: GPL protects this specific implementation and not the algorithm. Even if the authors released this under GPL, this would only be a minor nuisance to getting this unicorn into all kind of products via re-implementations of the same protocol.
anentropic 11y ago
am I the only one who doesn't understand the horizontal axis on their graphs: "Images sorted on compression ratio"? what does it mean that the FLIF lines suddenly get worse than PNG over on the right-hand side?
- jonsneyers 11y ago
  For each algorithm, the images are sorted from best (on the left) to worst (on the right). So if you look at the middle region of the graph, you see how they behave on "median" images. Another way to view the graph is: the area under the curve corresponds to the total disk space needed to store a large corpus of images in the given format. So obviously lower is better.
tzakrajs 11y ago
And the Weissman score is?
stolsvik 11y ago
For me, the license choice makes this project "interesting, but no way this is gonna fly!!", and I immediately think that this is a "try-before-you-buy"-usage of the GPL, to which there are many.
Mathnerd314 11y ago
I found what appears to be an early draft of the paper: http://webcache.googleusercontent.com/search?q=cache:z2rYA4ZilDoJ:https://svn.ulyssis.org/repos/sipa/jif/paper/jpif.tex http://webcache.googleusercontent.com/search?q=cache:z2rYA4Z...
MrBra 11y ago
Then it was written, that we had to be doomed by animations everywhere!
- dcposch 11y ago
  Anywhere on the internet where you can post an image today, you can already choose an animated GIF. If the site doesn't want animations, it will only show the first frame. For example, try uploading an animated GIF to Facebook.
MrBra 11y ago
> FLIF is based on MANIAC compression. MANIAC (Meta-Adaptive Near-zero Integer Arithmetic Coding) is an algorithm for entropy coding developed by Jon Sneyers and Pieter Wuille. It is a variant of CABAC (context-adaptive binary arithmetic coding), where instead of using a multi-dimensional array of quantized local image information, the contexts are nodes of decision trees which are dynamically learned at encode time. This means a much more image-specific context model can be used, resulting in better compression.
r-w 11y ago
I guess this would be considered a Las Vegas algorithm: https://en.wikipedia.org/wiki/Las_Vegas_algorithm https://en.wikipedia.org/wiki/Las_Vegas_algorithm § “Relation to Monte Carlo algorithms”

1254 points by davidbarker 11y ago

MasterScrat 11y ago

Sounds almost too good to be true... any major downside, other than current lack of support?

sprash 11y ago
FTA: "FLIF is a work in progress. The format is not finalized yet. Any small or large change in the algorithm will most likely mean that FLIF files encoded with an older version will no longer be correctly decoded by a newer version. Keep this in mind."
fsiefken 11y ago
Perhaps the MANIAC/CABAC decoding or encoding is computationally more intensive compared to the others? Concerning lack of support, just like with the BPG decoder you could generate the Javascript through Emscripten so any javaszcript enabled browser can view them. Personally an even more efficient lossy image compressor would be great (getting my avatar down to 1K and still sharp). When using diagrams or text the mozjpeg artifact eraser is adequate.
raving-richard 11y ago
Because it is GPL3, it won't be supported by Google on Android, by Apple probably anywhere, or by Microsoft anywhere. In other words, it's a lovely idea, but due to a poor choice of license, it won't get any adoption. C.f. Ogg Vorbis, where the license for the specification is public domain, and the license for the libraries are BSD-like. To quote FSF: Some libraries implement free standards that are competing against restricted standards, such as Ogg Vorbis (which competes against MP3 audio) and WebM (which competes against MPEG-4 video). For these projects, widespread use of the code is vital for advancing the cause of free software, and does more good than a copyleft on the project's code would do.[1] I would suggest that this is a case where widespread use is more important than copyleft. [1]　https://www.gnu.org/licenses/license-recommendations.html https://www.gnu.org/licenses/license-recommendations.html
- aaronharnly 11y ago
  Agree – using GPL rather than LGPL or BSD in the reference implementation will prevent this from being widely adopted. UPDATE: See lt's helpful comment above.
  - davexunit 11y ago
    So, the free world can use this library and the proprietary world will have to develop their own if they want to use the format. Proprietary software developers get to piggy back off of tons of free software, and then when someone decides that they don't want to enable that for their particular program/library, people complain about it. It makes no sense.
    - brianwawok 11y ago
      I think license depends on your goal. If your goal is to create a web image format.. you need all the browsers to agree to include you. All browsers will not add a GPLv3 image type. Therefore it is dead before it launched.
      - davexunit 11y ago
        The author has expressed interest in dual-licensing, so there will probably still be options. GPLv3+ or LGPLv3+ sounds reasonable.
        snuxoll 11y ago
        LGPLv3 will still prevent use of Windows Phone, iOS and Android.
        davexunit 11y ago
        No, that's backwards. Microsoft and Apple and Google prevent the usage of the GPL/LGPL. Don't blame the GPL for the bad behavior of large corporations that are using their immense power to try to stop copyleft.

T3RMINATED 11y ago

Request denied by WatchGuard HTTP Proxy. Reason: Category 'Newly Registered Websites'

fnordfnordfnord 11y ago
WatchGuard is a disease. They also listed Hackaday as banned for "Hacking". Ever try to get a site unlisted from them? It's nearly impossible, and may only last a month or so before it goes back on the blacklist.

StavrosK 11y ago

How does this unicorn achieve all this, and unencumbered by patents on top of everything else?

fnordfnordfnord 11y ago
A million monkeys, scratching their heads, looking for a better way to save/send their photo albums. Progress has been on order for a while now, someone(s) is/was bound to crack it sooner or later.
Daemon404 11y ago
I cannot imagine it truly is - it uses a variation of CABAC, which sure has patents related to it. I wonder if they had a real legal person OK that claim.

lt 11y ago

This is really interesting! There seems to be some additional technical information here: https://boards.openpandora.org/topic/18485-free-lossless-image-format-flif/ https://boards.openpandora.org/topic/18485-free-lossless-ima... - for interlacing it uses a generalization of PNG's Adam7; unlike PNG, the geometry of the 2D interlacing is exploited heavily to get better pixel estimation, which means the overhead of interlacing is small (vs simple scanline encoding, which has the benefit of locality so usually compresses better) - the colorspace is a lossless simplified variant of YIQ, alpha and Y channel are encoded first, chroma channels later - the real innovation is in the way the contexts are defined for the arithmetic coding: during encoding, a decision tree is constructed (a description of which is encoded in the compressed stream) which is a way to dynamically adapt the CABAC contexts to the specific encoded image. We have called this method "MANIAC", which is a backronym for "Meta-Adaptive Near-zero Integer Arithmetic Coding".

versteegen 11y ago
Great, thanks. It seems there is no technical description available anywhere beyond what you quoted. They haven't written it up, and I couldn't even find comments in the source providing details. That's too bad, but he (I assume that's Jon Sneyers) does say he hopes to write it up later. Also, comments in that thread on speed [1]: In terms of encode/decode speed: both are slow and not very optimized at the moment (no assembler code etc, just C++ code). A median file took 3 seconds to encode (1 second for a p25 file, 6 seconds for a p75 file), which is slower than most other algorithms: WebP took slightly less than a second for a median file (0.5s for p25, 2s for p75), PNG and JPEG2000 took about half a second. It's not that bad though: BPG took 9 seconds on a median file (2.5s for p25, 25s for p75), and brute-force pngcrushing took something like 15 seconds on a median file (6s for p25, over 30s for p75), so at least it's already better than that. Decode speed to restore the full lossless image and write it as a png is not so good: about 0.75s for a median file, 0.25s for a p25 file, 1.5s for a p75 file. That's roughly 3 to 5 times slower than the other algorithms. However, decoding a partial (lossy) file is much faster than decoding everything, so in a progressive decoding scenario, the difference would not be huge. [1]: https://boards.openpandora.org/topic/18485-free-lossless-image-format-flif/?page=2#comment-399001 https://boards.openpandora.org/topic/18485-free-lossless-ima...

deleted 11y ago

[deleted]

baldfat 11y ago

I don't see any foundations or corporations backing this project. Without support (I hope something like this does gain wide scale support (SVG in browsers for the Internet please already!) I don't see this being accepted.

pmelendez 11y ago
What you say it's true for a wide scale usage. However, imagine a small company, startup, or a sole developer using this for their projects or as a internal format. I found it very interesting even if there is not a widespread use of it.
- baldfat 11y ago
  It is interesting! I agree but I guess I am getting to old. I keep hearing awesome new formats and than they just waste away. The few success stories are few and in between. FLAC and OGG are a good example. OGG is a decent format and I prefer it to MP3 but it really just withered. FLAC is awesome but it is far from main stream. Heck even SVG is far from where it SHOULD be.
  - anc84 11y ago
    And then there is Opus which took the world in storm.
    - baldfat 11y ago
      It has the devices covered > Devices based on Google's Android platform, as of version 5.0 "Lollipop", support the Opus codecs. Chromecast supports Opus decoding. Grandstream GXV3240 and GXV3275 video IP phones support Opus audio both for encoding and decoding. Developers were Mozilla and Skype (MS after the purchase) >Its main developers are Jean-Marc Valin (Xiph.Org, Octasic, Mozilla Corporation), Koen Vos (Skype), and Timothy B. Terriberry (Xiph.Org, Mozilla Corporation). Among others, Juin-Hwey (Raymond) Chen (Broadcom), Gregory Maxwell (Xiph.Org, Wikimedia), and Christopher Montgomery (Xiph.Org) were also involved. Standardized > https://tools.ietf.org/html/rfc6716 https://tools.ietf.org/html/rfc6716 Still I think most people have no idea about Opus as a codex and only thing OGG (Container which Opus uses) and Vorbis codec format (Which Opus was to replace).

fnordfnordfnord 11y ago

Where are the images to compare? Bellard has a very neat demonstration on his page http://xooyoozoo.github.io/yolo-octo-bugfixes/#nymph&jpg=s&bpg=s http://xooyoozoo.github.io/yolo-octo-bugfixes/#nymph&jpg=s&b... BTW, credit to the flif people for linking competitor formats bpg and webP

adrianN 11y ago
It's lossless. They look just like the originals.
- fnordfnordfnord 11y ago
  Thanks. I had a derp moment. I guess I wasn't prepared to believe that "lossless" really meant lossless.
kcorbitt 11y ago
Well given that they're all lossless formats, the image should appear identical with any of the codecs, with only the file size (and encoding style) being different. More practically, since browsers won't have an flif decoder there isn't an easy way to embed the images online without reencoding them in a different format, which would rather defeat the purpose of putting up sample images.
- fnordfnordfnord 11y ago
  Oh! Derp! I guess I am used to marketing-level abuses of language. >More practically, since browsers won't have an flif decoder there isn't an easy way to embed the images online without reencoding them in a different format, which would rather defeat the purpose of putting up sample images. Did you follow the link I posted? I think Bellard put together a pretty nifty demo. Note: Bellard credits xiph.org as the originator of the demo page. http://people.xiph.org/~xiphmont/demo/daala/update1-tool2b.shtml http://people.xiph.org/~xiphmont/demo/daala/update1-tool2b.s...
- espadrine 11y ago
  They could demonstrate interlacing comparisons by slowing down (through setTimeout()) the image processing in the browser. Having a Youtube video already shows that it works really amazingly well (especially coming from Adam7), but seeing it interactively on a selection of images would be nice. After all, the single biggest feature is that you can actually stop downloading the image whenever you feel like you don't want to spend more bandwidth!

chmike 11y ago

I couldn't see any information on speed performances. There is certainly a price to pay for these impressive results. It could be the compression time. I hope not the uncompressing time.

pmelendez 11y ago
I am not relating to this project, but I am actually in the middle of the development of a 3d image retrieval server and this very interesting to my work right now. I will compare this using lodepng as a baseline and hope to report soon.
foldor 11y ago
I'm guessing that they're not releasing the numbers on that yet until the format is finalized. It's likely not gone through any serious optimizations yet.
- versteegen 11y ago
  See the quote I pulled out above: https://news.ycombinator.com/item?id=10318161 https://news.ycombinator.com/item?id=10318161

paxcoder 11y ago

I want to believe.

rwinn 11y ago

Wow! Higher compression than any other format, full transparency support, progressive/partial loading AND animations?! I can't wait for this to get widespread adoption! Github repo here btw: https://github.com/jonsneyers/FLIF https://github.com/jonsneyers/FLIF

digi_owl 11y ago
GPLv3 will be a hard sell...
- lucian1900 11y ago
  In fact, it makes it impossible to use in practice. None of the major browsers are GPLv3.
  - zanny 11y ago
    The GPL is compatible with BSD, MPL, and MIT licenses that Firefox / Chromium use. The problem is more that Firefox / Chrome ship proprietary bits like the DRM modules that would violate the linking GPL coverage of flif. And that Chrome is proprietary. Its going to need to be relicensed LGPL to be included.
    - snuxoll 11y ago
      > The GPL is compatible with BSD, MPL, and MIT licenses that Firefox / Chromium use. Yes, it is compatible, the other way around. You can take BSD, MPL, MIT code and adopt it into a GPL project, not the other way around. EDIT: Even LGPL won't work here as it will prevent use on Windows Phone, iOS and Android.
      - Someone 11y ago
        If Apple's attributions are correct (1), there is LGPL software on iOS, for example libiconv, and even GPL software (libgcc, libstdc++), but those have linking exceptions. WebKit also is partially LGPL. Possibly not coincidental, the latest LGPL version I could find in the 'legal' section is 2.1. (1) they may be overly cautious, given that they mention the L4 kernel, lua, and Tiny Scheme.

onion2k 11y ago

The 'only download as much of the file as you need' way of managing detail levels is brilliant.

kcorbitt 11y ago
Totally. I really recommend watching the video under the "Progressive and lossless" heading. With just 20% of the file downloaded the image quality was already subjectively quite good. I didn't even know progressive loading within a single file was a thing, but it's a neat trick.
- talmand 11y ago
  Isn't a progressive jpeg loaded from a single file? Or are you referring to a different context of progressive with this file type?
- linkydinkandyou 11y ago
  It's been a thing for at least 20 years, when "wavelet" compression first started being used. https://en.wikipedia.org/wiki/JPEG_2000#Progressive_transmission_by_pixel_and_resolution_accuracy https://en.wikipedia.org/wiki/JPEG_2000#Progressive_transmis... And the Digital Cinema formats widely used today rely on this so a 2K or 4K stream can be extracted from the same file. What's "new" about FLIF is the better lossless compression rate

iraphael 11y ago

This is really interesting. One of the most interesting parts is the progressive decoding/responsive images. http://flif.info/example.php http://flif.info/example.php (go to the bottom of the page). Basically, the last example shows that, if you want a scaled version of the image, you can simply stop decompressing. No need for multiple image files. Just create one with very high quality and decompress until you get the quality you want and scale it down with html. edit: more info on the responsive side of FLIF: http://flif.info/responsive.php http://flif.info/responsive.php

digi_owl 11y ago
Makes me think of the web of old, where sometimes an image would load in multiple passes.
- michaelmior 11y ago
  I assume you're talking about progressive JPEGs. These are still fairly common in my experience. It's just that with today's typical connection speed, you'll rarely notice.
  - masklinn 11y ago
    There's also progressive PNGs. Progressive JPEGs have the advantage that they increase compression ratio (though they're more expensive to decode, as you need multiple passes and refresh)
    - darkmighty 11y ago
      They increase compression ratio? That's counter-intuitive. You're effectively imposing an ordering requiring certain information to be available first, so you'd expect the compression be at most as good as non-progressive. I guess the changed ordering makes the statistics simpler and easier to compress, or something like that.
      - 11y ago

Navarr 11y ago

Obligatory XKCD: https://xkcd.com/927/ https://xkcd.com/927/ No but I'm excited, this is progress!

alphabetam 11y ago

GPL 3. Meaning it won't ever be adopted by anyone.

yiyus 11y ago
IANAL, but I guess the file format itself is not covered by the GPL 3, only the reference implementation. They specifically say that "FLIF is completely royalty-free and it is not encumbered by software patents". So, I suppose people will be allowed to develop their own libraries with another license.
- nstart 11y ago
  They also go on to say. That might be a clear indication that this is in fact GPL v3. FLIF is Free Software. It is released under the GNU General Public License (GPL) version 3 or any later version. That means you get the “four freedoms”: The freedom to run the program, for any purpose. The freedom to study how the program works, and adapt it to your needs. The freedom to redistribute copies. The freedom to improve the program, and release your improvements to the public, so that the whole community benefits.
- dagw 11y ago
  True, but the only complete documentation of the file format I found was the source code of the reference implementation. So the only way to write a new implementation is to study the reference implementation, which will make your new implementation "tainted".
  - antientropic 11y ago
    Studying GPL'ed source code does not "taint" anything. You're absolutely allowed to do that. If you're really concerned about subconsciously copying elements of the original into your implementation, you could let somebody else study the original and write a spec.
    - nickpsecurity 11y ago

jttam 11y ago

Does it use a middle out algorithm? :)

anandvc 11y ago
That's exactly what I was wondering! :)

hokkos 11y ago

It would be nice to have a comparison with https://en.wikipedia.org/wiki/JPEG_XR https://en.wikipedia.org/wiki/JPEG_XR

espadrine 11y ago

The most solid feature is lossless responsiveness. Stopping the download gives you a lower-resolution image. When scaled, the image then becomes lossy. Here is a thorough analysis of how good that lossy image is: http://flif.info/example.php http://flif.info/example.php It shows how very good lossy BPG is, but also how good FLIF is against anything but BPG (and against lossless BPG).

emergentcypher 11y ago

Why all the hate for GPLv3?

josteink 11y ago
Sharing code is no longer cool if people have to share back. Or at least so it seems. The GPL-hate in here really is quite immense, even though time and time again, RMS has been shown to be right about his stance on freedom. Should we attribute it to people's desire for a quick ("free") fix over long term considerations? It's hard to tell, but I suspect the silicon valley influence here doesn't help. There everyone wants to take everyone else's hard work and code, build a weekend SaaS and get rich. The GPL, while not preventing that, is clearly in opposition to that goal.
- versteegen 11y ago
  As someone who made a negative comment about the GPL elsewhere in this thread, I think I'll comment. I have absolutely nothing against the GPL, and use it myself. However, using the GPL for a library seems like a bad idea, because there are a lot of people, especially at companies, which won't touch the GPL. So if you license a library GPL and it's useful someone is just going to come along and reimplement it with a more liberal license. And such a waste of resources is sad to contemplate. The ideal of the GPL was that it would force other projects to switch to GPL, but it doesn't seem to happen too much in practice because the modern world has an abundance of alternative software for any task. Think long term: chances are someone in the next 50 years will be annoyed enough to reimplement whatever you're doing.
  - robert_foss 11y ago
    In the context of this project which is yet to have a finalized specification I think the GPL is an ideal format. As a project it is important to have access to all of the pieces and avoiding incompatible forks of different kinds in the early stages. So for the purpose of developing a 'golden standard' prototype for FLIF, I don't think a non-GPL license would have served them better. The author seems to have the same idea, and is considering re-licensing to MIT later on. I don't agree with corporate apologeticism which seems to be the norm here. If a company wants get something for free, expecting it to publish source code changes is not an actually high threshold. It might be in terms of corporate politics, but in actuality it is not hard.

donlzx 11y ago

I hope the idea of progressive downloading partials can be applied to other files types as well. For example, if commonly used libraries such as minified Javascript source files are encoded and distributed incrementally, we don't have to repetitively download various versions of the same library from different CDNs for different websites, which will save a huge amount of Web traffic.

russnewcomer 11y ago

I don't see any comparison here on the impact of decompressing? Is this going to hit a processor harder than JPG/PNG/BPG/et al will, and thus be a hit to people on mobile devices?

infogulch 11y ago
Decompression speed is important. (And more important than compression speed.) But the bottleneck on mobile devices is increasingly falling on the mobile network. CPU performance per watt is falling dramatically where mobile bandwidth per watt is staying relatively static. If this continues eventually we'll get to the point where the power usage (e.g. for loading and displaying a web page) is completely dominated by data transfer, and more and more computationally expensive compression becomes the best way to save overall power by trading cheap cpu cycles for expensive bandwidth.
logfromblammo 11y ago
Processor and storage are much cheaper than network bandwidth this year. The most relevant tradeoff calculation now would probably be bandwidth versus battery power consumption. The FLIF image decoding library might want to be battery-aware, such that it can automatically scale back the power consumption at lower battery charge levels, in a user-configurable fashion. Or perhaps it caches a fully decompressed or partially decompressed file to storage, so that it only does the battery-devouring steps once.

hknd 11y ago

Is this Pied Piper?

tempodox 11y ago

Those diagrams are incomprehensible. The sorted and unordered WTF-per-diagram rate is too frigging high.

robert_foss 11y ago

An interesting aspect that has not been mentioned on flif.info nor here, is the implementability on silicon. How many transistors would be needed for and encoder? How about a decoder or a codec (encoder/decoder)? And what about clock speed? How long is the longest pipeline in the codec? For any other modern codec the hardware aspect is a very important one. Usecases like smartphone browsers or smartwatches are very common, and on platforms like that performance==battery life==usefulness.

deleted 11y ago

[deleted]

lt 11y ago
This is lossless, not lossy. The output is the same.
- deleted 11y ago
  [deleted]
Steuard 11y ago
"Free Lossless Image Format": the quality metric for lossless images is "identical pixel by pixel to the reference format". (There's obviously a question about how to judge quality for a given partial download of a FLIF file, but for the total file there really isn't any question of quality metrics at all.)

tfinniga 11y ago

This is an exciting development. I think the concerns about the licensing are a bit premature - honestly, this is currently a research project, not a practical replacement for existing image formats. The licensing is only one of several impediments to adoption. - The format has no spec - The format may change, rendering all previous images unreadable - The format has no javascript implementation, and no way of running on old browsers. - As far as I can tell, there hasn't been a patent search done to see if it violates other patents from other organizations. For example, this one: http://www.google.com/patents/US7982641 http://www.google.com/patents/US7982641 - No peer-reviewed paper published yet? However that doesn't mean that we can't recognize the accomplishment - this looks like a very promising research result, and I hope the project continues! Good work Jon!

mmastrac 11y ago
> - No peer-reviewed paper published yet? While there's no paper there's a full Github repo which I'd actually say is quite impressive.
- joshvm 11y ago
  As someone who regularly has to read supposedly landmark papers - with no source code provided - this is far preferable in my opinion. Computer vision is terrible for this!
lcswi 11y ago
Screw software patents!

edubart 11y ago

I see you there Pied Piper, but will it still perform well on 3d?

ruffyen 11y ago

I think the important thing that needs to be addressed here before this file format takes hold is how the hell you are going to pronounce this format. I don't want another gif/gif debate.

antirez 11y ago

One would expect, in theory, Google to push this like mad, based on what they did with HTTP 2.0 in another part of the stack, for possibly less gain at the cost of much more complexity and standards shaking. Let's hope it really happens.

gok 11y ago

Comparing compression ratios without comparing compute/memory requirements is...not terribly meaningful.

shmerl 11y ago

> FLIF is completely royalty-free and it is not encumbered by software patents. That's good but does it actually avoid patent minefields that others scattered around? That's equally critical for healthy adoption.

boksiora 11y ago

looks great!!! i want to see it in my browser and websites, home some browser support come from chrome and firefox

happywolf 11y ago

Would like to point out a caveat listed in that page, as follows. Don't convert all your photos in your drive (yet). "WARNING: FLIF is a work in progress. The format is not finalized yet. Any small or large change in the algorithm will most likely mean that FLIF files encoded with an older version will no longer be correctly decoded by a newer version. Keep this in mind. "

natch 11y ago

One more nice feature they didn't mention: unambiguous pronunciation.

mdup 11y ago
So, is it eff-leef or fleef ?
- tricolon 11y ago
  /'flɪf/

kenOfYugen 11y ago

"A FLIF image can be loaded in different ‘variations’ from the same source file, by loading the file only partially. This makes it a very appropriate file format for responsive web design. " Awesome! I have been toying with custom png 'container' ideas in the past offering similar 'responsive' features (i.e various resolutions, lossy-lossless versions) I would like to see the ASM.js version of the decoder and see how that one performs.

cfv 11y ago

GPL for me is a dealbreaker. Can't use it unless I'm able to link to it without having my client relinquish his rights to his stuff.

proyb2 11y ago

Between Brotli and FLIF, which is good enough?

gillianseed 11y ago
Brotli is excellent at text and does a great job at compressing overall, but FLIF is written directly to excel at lossless image compression, hence FLIF will be much better unless it's a really poor solution (which results show it's certainly not). Likewise Brotli will not beat FLAC at compressing audio, since FLAC is specifically written to do that.
- robryk 11y ago
  Actually, FLAC doesn't have a very good compression ratio (e.g. see [1]). It does have features that are very important for audio streams: it can be quickly resynced and AFAIK decompression proceeds at nearly-constant speed. [1] https://news.ycombinator.com/item?id=7893171 https://news.ycombinator.com/item?id=7893171
  - gillianseed 11y ago
    Even so, I would be very surprised if FLAC did not outperform general purpose compressors if the test is done on a wider range of music than a single piano piece (which should be very compressable overall as audio goes). edit: went and did a test on a couple of tracks, using brotli: bro --quality 11 --window 24 against flac -8 (best settings in both cases) satie - gymnopedie no 1: wav: 41.6mb brotli: 28.1mb flac: 14.7mb ram jam - black betty: wav: 41.8 brotli: 35.8 flac: 26.5 vangelis - tao of love: wav: 29.4 brotli: 23.0 flac: 13.4 meat load - paradise by the dashboard light: wav: 89.3 brotli: 78.3 flac: 58.5 certainly not a massive test, and there are likely general purpose compressors which does a better job than brotli, still I feel rather convinced that they will not do better than FLAC other than in extreme cases such as the piano piece you linked to.

joelthelion 11y ago

How cpu-intensive is it? Decompression speed can be an issue, especially on mobile.

matheweis 11y ago
Here is what he says about that: https://boards.openpandora.org/topic/18485-free-lossless-image-format-flif/?do=findComment&comment=399001 https://boards.openpandora.org/topic/18485-free-lossless-ima... Decode speed to restore the full lossless image and write it as a png is not so good: about 0.75s for a median file, 0.25s for a p25 file, 1.5s for a p75 file. That's roughly 3 to 5 times slower than the other algorithms. However, decoding a partial (lossy) file is much faster than decoding everything, so in a progressive decoding scenario, the difference would not be huge. There's still room for optimizing the encode/decode speed, but it's not very useful to do that before the bitstream is somewhat finalized. The prototype implementation I have now is not extremely fast, but at least it's in the right ballpark. Most likely even an optimized decoder will still be slower than an optimized PNG decoder, but the difference will be small enough to not matter much (certainly compared to the time won by downloading less bytes). comradekingu likes this

spullara 11y ago

One of the least interesting parts of this is that it is GPL. Someone should reimplement it with a BSD license so it can be used more widely. AFAIK & IANAL, but I don't think you could integrate this with FF, Chrome, Safari or IE.

jblow 11y ago
No kidding. If you want an image format to become widely adopted and standardized, GPLing the code is a pretty bad idea.
- Aldo_MX 11y ago
  Not just an image format, everything you want to become widely adopted and standardized should refrain from using the GPL, even the FSF[1] recommends using the Apache License in this specific case. Some libraries implement free standards that are competing against restricted standards, such as Ogg Vorbis (which competes against MP3 audio) and WebM (which competes against MPEG-4 video). For these projects, widespread use of the code is vital for advancing the cause of free software, and does more good than a copyleft on the project's code would do. In these special situations, we recommend the Apache License 2.0. [1] https://www.gnu.org/licenses/license-recommendations.html https://www.gnu.org/licenses/license-recommendations.html
  - bloody_pretzels 11y ago
    Note that the Apache License isn't compatible with GPLv2. If you don't make use of any patents use BSD/MIT/ISC instead. Sadly there isn't a real alternative permissive license with a patent clause. There is a license called COIL[1], but it hasn't seen much adoption yet. [1] http://coil.apotheon.org/ http://coil.apotheon.org/
    - Aldo_MX 11y ago
      Nothing that a dual license GPL/APL wouldn't solve.
- 11y ago

whatever_dude 11y ago

Sounds amazing. But: no information on encoding time. I'm assuming it's going to be a beast. Which, IMO, is totally fine.

rancur 11y ago

BMP is free isn't it????

rancur 11y ago
I guess trollers/jokesters aren't appreciated here...

shaikharbaz 11y ago

I imagine images appearing as fast as I can scroll, with enough visual clue to them to find images way way more quickly than with thumbnails today. As a start, thumbnails could use <a href="http://www.hookad.com">post</a> http://www.hookad.com">post</a>

williamsharkey 11y ago

Can the progressive data obscure previous portions of the image? If so, it can also be a hacky video format. EG: A flif would specify how many megabytes it used per second. There would not be discrete "frames". If a video flif said that it used 1MB per Second, and you wanted to see what the video looked like at 10.8 seconds, you would download 10.8MB .

yekim 11y ago

Pretty sweet. Will be interesting to see where this lib goes. If someone has some time, maybe they could give it a mention on the Wikipedia page: https://en.wikipedia.org/wiki/Image_file_formats https://en.wikipedia.org/wiki/Image_file_formats

dnesteruk 11y ago

Doesn't the GPL license generally ruin being able to use this in a commercial product by having to provide source code and affecting derivative works, too?

andrepd 11y ago

I wonder how it compares to lossy (but high-quality) compression codecs.

jonsneyers 11y ago

To clarify: at the moment FLIF is licensed under the GPL v3+. Once the format is finalized, the next logical step would be to make a library version of it, which will be most probably get licensed under the LGPL v3+, or maybe something even more permissive. There is not much point in doing that when the format is not yet stable. It's not because FLIF is GPL v3+ now, that we can't add more permissive licenses later. And of course I'm planning to describe the algorithms and the exact file format in a detailed and public specification, which should be accurate enough to allow anyone to write their own FLIF implementation.

bhouston 11y ago
Very neat stuff. Would be nice to support 16/32bit floating point for true HDR as well if can be easily accommodated.
- jonsneyers 11y ago
  Can be done. Basically just change the type of ColorVal and implement a float variant of writer() and reader() in maniac/symbol.h.
  - alanh 11y ago
    I want to chime in to say that the lack of a common image format (and displays, for that matter) with true support for high-range photos is really holding back digital photography in my humble opinion.
    - Tloewald 11y ago
      Nah, it's the camera makers that are holding things back by sticking to proprietary formats and in some cases obfuscating them. There's OpenEXR, HDR, and DNG (the last of which is a true RAW format). The big issue with creating a true interchange format is that RAW files don't have proper color information for all pixels (they instead have red, green, or blue data for any given pixel, sometimes deliberately blurred, etc.) and interpolating the values to produce reasonably nice faux color for each pixel is actually very hard and the algorithms the different companies use is presumably protected by patents.

cbr 11y ago

They claim this is good for responsive images: The download or file read operations can be stopped as soon as sufficient detail is available, and if needed, it can be resumed when for whatever reason more detail is needed. -- http://flif.info/responsive.php Unfortunately that's not how HTTP works. Your browser opens several connections to a website, and makes requests for resources. Each connection is in use until that resource is fully loaded, at which point you can send a request for another resource up that connection. Yes, the browser could close the connection after it has received enough of the image for the desired quality, but there's a lot of overhead in setting up a new connection, including some round trips, and so that is probably a net loss. The JPEG image format also supports progressive images, in browsers today, and no one has figured out how to use that for single-file responsive images yet. (You might be able to do something in HTTP/2 where you set the priority of the stream to 0 after you have enough of it for your needs, but I don't think anyone has gotten this working yet.)

XCSme 11y ago
Why do you say it is a net loss? Maybe the server could signal the end of file based on some request parameters (the resolution of the image).
- AshleysBrain 11y ago
  Yes, handling it on the server side sounds like a reasonable workaround. For example photo.flif?res=1x returns Content-Length: 100000, and photo.flif?res=2x returns Content-Length: 200000, with both returning data from the same file.
- cbr 11y ago
  I say net loss because with current http the loss of closing the connection is typically much higher than the loss of downloading more bytes than you need. Connection reestablishment needs a lot of round trips.
szym 11y ago
Could use range requests (RFC 7233), albeit with some overhead.

arasmussen 11y ago

How does it compare to slightly lossy jpegs?

jaigouk 11y ago

wow. this is amazing!

URSpider94 11y ago

I don't see how the author can claim that FLIF is "unencumbered by software patents," only that he/she hasn't obtained patents on the work already. This has traditionally been one of the problem with so-called "free" image formats -- it's not that the standards body or creator asserts patent rights, it's that other inventors claim that their pre-existing patents cover the new format.

jmspring 11y ago

Ignoring patents is a concern. The patent issue is a major one and not lightly ignored. I haven't checked patent status, but one of the things that was pretty contentious with JPEG 2000 during the ISO standardization process was patents around arithmetic coding -- not just the method for doing the encoding, but also things like context based modeling. In reality, the majority of image compression comes about in the "modeling" stage -- be it predictive coding, context based encoding coefficients, etc. I'm happy to see new advances in image coding, but having spent many years working with Glen Langdon and others, the depth of IP concerns is still fairly fresh in my memory.

tracker1 11y ago

GPLv3 will make adoption problematic... if it were at least LGPL so that it could be used as a library that would make adoption far more likely.

waynecochran 11y ago

BE SKEPTICAL! Not a single mention of "signal to noise ratio" (SNR). If you are going to list compression rates you have to give the associated quality -- SNR is used in the literature. I was suckered into "fractal image compression" by those selling the snake oil back in the 90's -- I am far more skeptical about these things now.

GhotiFish 11y ago
could you go into detail about what you mean with "associated quality"? These are lossless compression algorithms that are being compared here. The only other pertinent details regarding a lossless compression algorithm are the Compression Ratio, CPU usage, and Memory usage.
- waynecochran 11y ago
  Because I am an idiot. Disregard. Move along.

hellcatv 11y ago

How does this compare to packpnm http://packjpg.encode.ru/?page_id=73 http://packjpg.encode.ru/?page_id=73

hngiszmo 11y ago

For all the GPL-hate in this thread: GPL protects this specific implementation and not the algorithm. Even if the authors released this under GPL, this would only be a minor nuisance to getting this unicorn into all kind of products via re-implementations of the same protocol.

anentropic 11y ago

am I the only one who doesn't understand the horizontal axis on their graphs: "Images sorted on compression ratio"? what does it mean that the FLIF lines suddenly get worse than PNG over on the right-hand side?

jonsneyers 11y ago
For each algorithm, the images are sorted from best (on the left) to worst (on the right). So if you look at the middle region of the graph, you see how they behave on "median" images. Another way to view the graph is: the area under the curve corresponds to the total disk space needed to store a large corpus of images in the given format. So obviously lower is better.

tzakrajs 11y ago

And the Weissman score is?

stolsvik 11y ago

For me, the license choice makes this project "interesting, but no way this is gonna fly!!", and I immediately think that this is a "try-before-you-buy"-usage of the GPL, to which there are many.

Mathnerd314 11y ago

I found what appears to be an early draft of the paper: http://webcache.googleusercontent.com/search?q=cache:z2rYA4ZilDoJ:https://svn.ulyssis.org/repos/sipa/jif/paper/jpif.tex http://webcache.googleusercontent.com/search?q=cache:z2rYA4Z...

MrBra 11y ago

Then it was written, that we had to be doomed by animations everywhere!

dcposch 11y ago
Anywhere on the internet where you can post an image today, you can already choose an animated GIF. If the site doesn't want animations, it will only show the first frame. For example, try uploading an animated GIF to Facebook.

MrBra 11y ago

> FLIF is based on MANIAC compression. MANIAC (Meta-Adaptive Near-zero Integer Arithmetic Coding) is an algorithm for entropy coding developed by Jon Sneyers and Pieter Wuille. It is a variant of CABAC (context-adaptive binary arithmetic coding), where instead of using a multi-dimensional array of quantized local image information, the contexts are nodes of decision trees which are dynamically learned at encode time. This means a much more image-specific context model can be used, resulting in better compression.

r-w 11y ago

I guess this would be considered a Las Vegas algorithm: https://en.wikipedia.org/wiki/Las_Vegas_algorithm https://en.wikipedia.org/wiki/Las_Vegas_algorithm § “Relation to Monte Carlo algorithms”