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

21–30 of 153 posts

Re: FLIF – Free Lossless Image Format

#22

Post by p4bl0 »

baldfat wrote: post #16
p4bl0 wrote: post #3

There was a previous discussion on HN about this: https://news.ycombinator.com/item?id=10317790

5 months ago. This is my first time seeing this item.

My point is not that it shouldn't be there again, it's that some potentially interesting stuffs have already been discussed, so the previous thread is probably worth a look too.

Re: FLIF – Free Lossless Image Format

#23

Post by panic »

AshleysBrain wrote: post #5

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: https://discourse.wicg.io/t/custom-image-audio-video-codec-a...

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

Re: FLIF – Free Lossless Image Format

#24

Post by eis »

imaginenore wrote: post #20
billpg wrote: post #11

Earlier quoted context omitted.

The browser would cache a copy. I've seen proposals to add hashes to links. This way, a browser might see a link to some JS on a new URL, but with the hash, it might find it already has that JS file in its cache from when it downloaded it at a different URL.

That's what Etag is for.

No it's not. Etag is completely different. It's a tag that the webserver sends together with the response and which the browser sends to the server which can then return a 304 status code to indicate that the resource has not changed and the browser can use the cached copy.

What the parent spoke about is adding some attribute to an anchor tag which specifies the hash of the resource so the browser can do safe cross domain caching without needing to do any request whatsoever.

Re: FLIF – Free Lossless Image Format

#26

Post by sjwright »

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.

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.

Re: FLIF – Free Lossless Image Format

#29

Post by techdragon »

eis wrote: post #24
imaginenore wrote: post #20

Earlier quoted context omitted.

That's what Etag is for.

No it's not. Etag is completely different. It's a tag that the webserver sends together with the response and which the browser sends to the server which can then return a 304 status code to indicate that the resource has not changed and the browser can use the cached copy. What the parent spoke about is adding some attribute to an anchor tag which specifies the hash of the resource so the browser can do safe cross d…

Just what we need... More ways to shoot our own feet off while trying to improve performance.

Re: FLIF – Free Lossless Image Format

#30

Post by Zardoz84 »

eddieh wrote: post #28

Honest question. Seriously not trying to dismiss the work. 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. https://en.wikipedia.org/wiki/Tagged_Image_File_Format

Because isn't open source, and is a proprietary format from Adobe ?
Post reply on HN