Everyone loves the "responsive loading" feature, but that's not even the novel thing about the format (JPEG 2000 did it even better — 16 years ago)! The novel feature of this format is better entropy coding.<p>FLIF decoder adds interpolation to make incomplete scans look nicer than in PNG, but that's a feature of the decoder, not the file format, so there's nothing stopping existing PNG decoders from copying that feature.<p>Note that it's generally not desirable to have FLIF used on the Web. A decent-quality JPEG will load at full resolution quicker than it takes FLIF to show a half-resolution preview.<p>FLIF is a lossless format, and lossless is a very hard and <i>costly</i> constraint. Images that aren't technically lossless, but <i>look lossless</i> to the naked eye can be half the size.<p>e.g. Monkey image from <a href="https://uprootlabs.github.io/poly-flif/" rel="nofollow">https://uprootlabs.github.io/poly-flif/</a> is 700KB in FLIF, but 300KB in high-quality JPEG at q=90 without chroma subsampling (i.e. settings good even for text/line-art), and this photo looks fine even at 140KB JPEG (80% smaller than FLIF).<p>So you want FLIF for archival, editing and interchange of image originals, but even the best lossless format is a waste of bytes when used for distribution to end users.
Do any of these newer/experimental schemes, such as this one, take into account other factors such as CPU load before declaring themselves as "better". For example this project seems pretty cool, but there's no data on how CPU bound, memory bound, I/O bound its decompression algorithm is.<p>I guess what I'm asking is, if I hit a web page with 20 images @ 100k per image is it going to nail one or more cores at 100% and drain the battery on my portable device. Fantastic compression is great but what are the trade offs?
Incredible work. My only comment is that the progressive loading example reveals that their algorithm seems to have desirable properties for lossy compression as well. Why not make FLIF support lossy and lossless? It's hard enough to get a new image format standardized as it is; offering a lossy mode would effectively give us a two-for-one deal.<p>If PNG had a lossy mode that was even slightly better than JPEG (or exactly as good but with full alpha channel support) it would have eventually supplanted JPEG just as it has now supplanted GIF.
There was a previous discussion on HN about this: <a href="https://news.ycombinator.com/item?id=10317790" rel="nofollow">https://news.ycombinator.com/item?id=10317790</a>
This looks promising! They ought to include time-to-decode in the performance numbers, though: a smaller compressed size doesn't matter if the process of loading and displaying the image takes more time overall. A graph like the ones on this page would be awesome: <a href="http://cbloomrants.blogspot.com/2015/03/03-02-15-oodle-lz-pareto-frontier.html" rel="nofollow">http://cbloomrants.blogspot.com/2015/03/03-02-15-oodle-lz-pa...</a>
If browsers supported APIs to allow "native" image/video/audio codecs to be written in JS, we could support new formats like this without needing any co-operation from the (very conservative) browser vendors. I wrote a proposal for this here: <a href="https://discourse.wicg.io/t/custom-image-audio-video-codec-apis/1270" rel="nofollow">https://discourse.wicg.io/t/custom-image-audio-video-codec-a...</a>
16 bit per channel and on future support for CMYK. Looks like a interesting alternative to TIFF for digital preservation. Sadly, the actual recommended format is TIFF (so, waste of storage space) -> <a href="http://www.loc.gov/preservation/resources/rfs/stillimg.html" rel="nofollow">http://www.loc.gov/preservation/resources/rfs/stillimg.html</a>
Pretty amazing! Particularly nice is that an alpha channel and animation are also possible.<p>One critical sidenode: it seems FLIF is still not as good as JPEG when used as lossy compression (this is something the benchmarks do not show well).<p>For example, go to <a href="http://uprootlabs.github.io/poly-flif/" rel="nofollow">http://uprootlabs.github.io/poly-flif/</a>, choose the monkey image, choose 'comparing with same size JPG', and set truncation to 60% or more.<p>Also, I'm not sure how efficient en- and decoding is for FLIF.
FLIF really is awesome :) Here's an analysis that compares FLIF to other common lossless image formats such as: PNG, WebP and BPG.
<a href="http://cloudinary.com/blog/flif_the_new_lossless_image_format_that_outperforms_png_webp_and_bpg" rel="nofollow">http://cloudinary.com/blog/flif_the_new_lossless_image_forma...</a>
Hmm, this has real potential as an archiving format for video, too.<p>Any news on what the processing overhead is like for viewing rather than creating the files? Is it less than PNG?
I'd like to see some comparisons with palettized PNGs. All the demo images for poly-flif use more than 256 colors, but diagrams and line art sometimes use 256 colors or less, which means they can be stored in an 8-bit palettized PNG losslessly. People often forget about this when optimizing PNG sizes, and most graphics software saves as RGB by default even when the image will fit in 8-bit palettized.
Seems cool. Slightly off topic but I hate when someone names a file format with "format" or "file" in the name. Isn't it a bit redundant to include format in the format? Something that has always bothered me about PDF.
When is this going to be available for DICOM medical images? :)<p><a href="http://dicom.nema.org" rel="nofollow">http://dicom.nema.org</a>
Looks amazing! Really impressive results. Very cool that progressive loading is composed into the format.<p>However I am afraid that without support from biggest companies the format will never gain popularity. Just think how long it took to make PNG a web standard. And animated PNGs? Died unnoticed. To make things worse, GIF, a stinking leftover from '90, is still in use (even on HN!).
Looks neat, but recently I discovered farbfeld[1] and I think I'll be sticking with that for the time being. I'm starting to believe data-specific compression algorithms are the wrong way to go.<p>[1]<a href="http://tools.suckless.org/farbfeld/" rel="nofollow">http://tools.suckless.org/farbfeld/</a>
For browser support (Servo), FLIF has an issue pointing to Rust's common image library: <a href="https://github.com/FLIF-hub/FLIF/issues/142" rel="nofollow">https://github.com/FLIF-hub/FLIF/issues/142</a>
This is probably the 3rd "replacement" for JPEG I have seen on HN in the last few years. None of these formats have been supported by common browsers. When will this stuff start making its way to the desktop?
I'm curious about patent/ licensing restrictions.<p>From what I gather it is patent free and the implementation is GPLv3?<p>Does this mean someone else could make a compatible encoder/decoder with a less restrictive license?
Kudos on this @jonsneyers! I've been looking at it ever since we talked at FOSDEM. Glad to see you getting some press on the work and good luck with Uproot Labs!
Honest question. Seriously not trying to dismiss the work.<p>Why not TIFF? 30 years old, already built into nearly every graphics application, supports everything this proposes and more. Plus it is already supported in Safari.<p><a href="https://en.wikipedia.org/wiki/Tagged_Image_File_Format" rel="nofollow">https://en.wikipedia.org/wiki/Tagged_Image_File_Format</a>