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

141–150 of 153 posts

Re: FLIF – Free Lossless Image Format

#141

Post by lucaspiller »

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 wrote a Chrome plugin that does exactly this. I was living in an apartment with a heavily metered connection, and wanted a way to block large header images and 40mb GIFs. The extension let's you set a maximum image size, and uses the HTTP Range header to request only that much of the image - it's pretty naive but it works. Here is an example from Facebook, with the limit set to 10kB:

http://imgur.com/a/l2qGz

Unfortunately browsers don't do anything smart in terms of requesting progressive images, as there isn't an easy way to figure out how much of an image should be downloaded. So even on a 320x400px low end mobile device, you'll still end up downloading the whole the 2000x2000 header image - the only difference is it'll appear quicker as it is progressively rendered.

https://github.com/lucaspiller/block-large-media

Re: FLIF – Free Lossless Image Format

#143

Post by Vendan »

vram22 wrote: post #121
panic wrote: post #23

Earlier quoted context omitted.

Please, no! The web already makes my phone heat up enough as it is.

Just had a wild thought: I wonder how different the web would be [1] if all data was sent in binary instead of some (text, HTML, JS) being sent in text format. Or do some servers and clients gzip the text automatically before sending it. I've heard of stuff like that (and seen HTTP headers related to it), but haven't looked deeply into it. [1] I mean in terms of speed. But there could be tradeoffs, because, though se…

almost all servers support compression nowadays, and most clients as well. The HTTP headers and such won't get compressed, but there's a very good chance that every page and text asset you get has been compressed in transit. Some servers even have the option of precompressing assets and delivering them without having to stream through a compression algorithm, but that only works with static assets.

Re: FLIF – Free Lossless Image Format

#144

Post by matzipan »

pferde wrote: post #101
matzipan wrote: post #41

Earlier quoted context omitted.

It was not born out of necessity. It was born because of the way your brain percieves the images. There is no need in adding detail if your brain can live happily without it. And if FLIF achieves such great lossless compression, imagine what amazing compression you can achieve with lossy compression.

Let's take a step back. Why did developers start to think about how the brain perceives details and how to trick it in the first place? Out of a necessity to save bandwidth and/or storage space.

You have a point. But I also like fast, snappy websites :P

Re: FLIF – Free Lossless Image Format

#145

Post by matzipan »

pmontra wrote: post #96
matzipan wrote: post #13

Earlier quoted context omitted.

How often do you need lossless images on the web? Almost never.

All those animated GIFs around the web, plus the images were JPEG artefacts would be noticed. Examples: The Y logo in the top left of this page is a GIF. All the logos at http://www.ycombinator.com/ plus the six images below More Quotes are PNGs.

Forgot PNG is lossless :P

Re: FLIF – Free Lossless Image Format

#146

Post by jonsneyers »

mrob wrote: post #95

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.

FLIF can also do palettes, without arbitrary limits on the palette size. It will automatically use palettes if the image has sparse colors (and "color buckets" if it has too many colors for a palette but still relatively few). It tends to be better than PNG in terms of compression, also for palette images. I haven't looked at optimizing palette ordering yet though, so there is probably some more margin for improvement here.

Re: FLIF – Free Lossless Image Format

#147

Post by jonsneyers »

thebeardisred wrote: post #135

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!

Hi, redbeard is it? I think you misremember something, I didn't start working at Uproot Labs but at Cloudinary.

As you can see we went for Apache2 (decoder) and LGPLv3 (encoder) shortly after FOSDEM.

Re: FLIF – Free Lossless Image Format

#148

Post by teh_klev »

dalke wrote: post #100
teh_klev wrote: post #74

Earlier quoted context omitted.

It says: "Encoding and decoding speeds are acceptable, but should be improved" But that doesn't address resource usage such as CPU, battery.

It's hard for a single author/developer to fully explore solution space. For example, it could be that Javascript acquires special primitives to decode these images, or that they be a common Javascript engine extension, with a polyfill fallback. It could be that these extensions make effective use of CPU-specific instructions, or that the underlying hardware contains special silicon to decode these images, similar to…

Appreciate the time spent answering this.

Re: FLIF – Free Lossless Image Format

#149

Post by chris_wot »

anon1385 wrote: post #15
chris_wot wrote: post #2

I wonder if IE will adopt it? Firefox and Chrome are very responsive, Microsoft not so much.

Firefox is very conservative when it comes to image formats - more so than any of the other browsers.. See WebP[1], JPEG2000[2] and JPEG-XR[3]. I'd be very surprised if they supported this. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=856375 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=36351 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=500500

That's a fairly convincing argument, I definitely need to concede the point here. Appreciate your insight and helpful links!

Re: FLIF – Free Lossless Image Format

#150

Post by vram22 »

Vendan wrote: post #143
vram22 wrote: post #121

Earlier quoted context omitted.

Just had a wild thought: I wonder how different the web would be [1] if all data was sent in binary instead of some (text, HTML, JS) being sent in text format. Or do some servers and clients gzip the text automatically before sending it. I've heard of stuff like that (and seen HTTP headers related to it), but haven't looked deeply into it. [1] I mean in terms of speed. But there could be tradeoffs, because, though se…

almost all servers support compression nowadays, and most clients as well. The HTTP headers and such won't get compressed, but there's a very good chance that every page and text asset you get has been compressed in transit. Some servers even have the option of precompressing assets and delivering them without having to stream through a compression algorithm, but that only works with static assets.

Interesting, that second point. Wonder how it is done. Via some background process that keeps monitoring asset dirs for new files, or does the user have to run a tool for that whenever they add new assets.
Post reply on HN