Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FLIF – Free Lossless Image Format

flif.info

Post reply on HN
Print view View original

111–120 of 153 posts

Re: FLIF – Free Lossless Image Format

#111

Post by Justsignedup »

pornel wrote: post #80

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. 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 featu…

A lossless format would be great on cameras as the current RAW format has image data which is uncompressed and thus space consuming. Having a really good lossless compression there can save on space and writes.

Re: FLIF – Free Lossless Image Format

#112

Post by acdha »

ktRolster wrote: post #91
pornel wrote: post #80

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. 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 featu…

>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)! Interlaced GIFs did it ~30 years ago.

That's not quite the same: an interlaced GIF loads with gaps and still requires a fair amount of data to be loaded before it can start displaying.

JPEG 2000's approach provides successively finer detail so the entire image can be rendered after only a small percentage of the total data has been received and then it just becomes sharper as data continues to stream in. If the rollout hadn't been so unsuccessful, this would have been a great answer for responsive images since you could have a single image served (and cached on your CDN) and clients could make ranged requests for the first n bytes based on the displayed size.

Re: FLIF – Free Lossless Image Format

#113

Post by acdha »

ant6n wrote: post #58
Houshalter wrote: post #51

Earlier quoted context omitted.

But that's another advantage. Each image would have to be distributed alongside it's javascript decoder. Even if the format is abandoned, the decoder will still be there, and it will still work on that webpage.

Which means you need JavaScript just to look at the file. Does web archive store js along with the content?

Yes – modern web archiving tools capture JavaScript, CSS, etc. The basic support where they just download URLs found in HTML has been around for years but the current best-practice is to use a real browser engine (e.g. PhantomJS, Firefox) which has either been integrated to store directly or simply is using a proxy like https://github.com/internetarchive/warcprox which adds every requested resource to a WARC file (https://en.wikipedia.org/wiki/Web_ARChive).

Re: FLIF – Free Lossless Image Format

#115

Post by jaredcheeda »

panic wrote: post #19

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: http://cbloomrants.blogspot.com/2015/03/03-02-15-oodle-lz-pa...

The FLIF format isn't finished yet. There are optimizations still being made both in compression ratio and decoding performance. Encoding performance is a lower priority.

Also it wouldn't really be a fair comparison to show this slowly maturing format's decoding time versus that of formats that have had decades of time for people to research and find the best ways for decoding (even hardware tailored). You're comparing the heavy weight champ against the up and comer with a lot of promise. FLIF would get pretty beat up in that comparison, but perhaps only because it isn't even finished yet, and thus hasn't had the time to reach that level of efficiency. From having used it, and played around with it, it seems to be pretty fast. Fast enough that people wouldn't notice a perceptible difference between it and other common formats. I think the current decode time is about 20 MegaBytes per second. Which is faster than most people's internet, and considerably larger than most people's images (on the web).

Once it's bitstream has been finalized and it starts to get some use, we'll see decoders improve their performance. The initial plan was to lock the bitstream for a 2016 release, and then in a year or two release a new bitstream with further improvements. Similar to GIFv87a (1987 version) and GIFv89a (1989 version with improvements and new features). However this may have changed as the FLIF 2016 release was set for late December, then February, and has been pushed back again.

In due time we'll see more accurately how the format compares to the existing champs in terms of performance.

Re: FLIF – Free Lossless Image Format

#116

Post by nfriedly »

JoshTriplett wrote: post #85
pornel wrote: post #80

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. 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 featu…

> 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. On the other hand, this allows browsers on metered-bandwidth connections to control bandwidth more effectively. Rather than disabling images entirely, this would allow loading a low-resolution version and stopping, and letting the user…

I would love to see this. Instead of network operators throttling bandwidth and/or re-compressing images, set a sane default and let the user have ultimate control.

Re: FLIF – Free Lossless Image Format

#117

Post by stan_rogers »

Justsignedup wrote: post #111
pornel wrote: post #80

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. 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 featu…

A lossless format would be great on cameras as the current RAW format has image data which is uncompressed and thus space consuming. Having a really good lossless compression there can save on space and writes.

Most camera raw image files (not RAW, since it's not an extension or a standard) are compressed, and have been for many years now. Some of them (notably the recent Sony standard ARW files, though it's a selectable option in some other brands) even use lossy compression for parts of the data. Yes, the files can take up a lot of space, but not nearly as much as a compressed 16-bit-per-channel RGB TIFF.

Re: FLIF – Free Lossless Image Format

#118

Post by pornel »

JoshTriplett wrote: post #85
pornel wrote: post #80

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. 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 featu…

> 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. On the other hand, this allows browsers on metered-bandwidth connections to control bandwidth more effectively. Rather than disabling images entirely, this would allow loading a low-resolution version and stopping, and letting the user…

Again, this is not new in FLIF, and it isn't a strength of the format. You're describing exactly what can already be done with progressive JPEG better.

Look at https://uprootlabs.github.io/poly-flif/ - set truncation to 80-90% and compare to Same Size JPEG.

Truncated FLIF looks like a pixelated mess, whereas JPEG at the same byte size is almost like the original (note that the site has encoded JPEG to have few progressive scans, so sometimes you get half image perfect and half blocky. This is configurable in JPEG and could be equalized to entire image being ok-ish).

Re: FLIF – Free Lossless Image Format

#119

Post by jaredcheeda »

mitchtbaum wrote: post #55

For browser support (Servo), FLIF has an issue pointing to Rust's common image library: https://github.com/FLIF-hub/FLIF/issues/142

For clarification, on the FLIF GitHub "Issues page", there is a ticket indicating an intention to build FLIF into FireFox's rendering engine Gecko, and also Servo (which will eventually replace Gecko). This ticket is a placeholder declaring Servo's interest in FLIF once it is finalized.

FLIF does not have an problem preventing it from pointing to a common Rust image library. (which is how I originally read it).

Re: FLIF – Free Lossless Image Format

#120

Post by pornel »

jonsneyers wrote: post #104
pornel wrote: post #80

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. 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 featu…

I agree with all of your comments. Some remarks though: (Disclaimer: I'm the author of FLIF) - interpolation is not the only difference between PNG and FLIF in terms of progressive decoding. Another difference is that instead of doing the interlacing on RGB pixels, it does it on YCoCg pixels with priority given to Y, so intermediate steps are effectively chroma subsampled (or in other words you get luma faster at hig…

Thanks! Sorry to rain on your parade :)

> In future work: Progressive JPEG with the Huffman encoding replaced by FLIF's MANIAC entropy coding should be an interesting direction...

That would be super cool.

Post reply on HN