Live data from Hacker News

FLIF – Free Lossless Image Format

flif.info

11–20 of 153 posts

Re: FLIF – Free Lossless Image Format

#11
post #6

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

So you would need to load up the JS decompressor every single time you load a webpage? Or is there another way to do it efficiently ?

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.

Re: FLIF – Free Lossless Image Format

#12
post #6

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

So you would need to load up the JS decompressor every single time you load a webpage? Or is there another way to do it efficiently ?

[deleted]

Re: FLIF – Free Lossless Image Format

#14
post #8

Does anybody understand how lossless JPEG works? To my mind, the whole point of JPEG is to get rid of high-frequency components.

https://en.wikipedia.org/wiki/Lossless_JPEG

It's a completely different algorithm, surprisingly, based around "predictors" from nearby previously-decoded pixels. Quite like Floyd-Steinberg dithering.

Re: FLIF – Free Lossless Image Format

#15

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

Re: FLIF – Free Lossless Image Format

#17
post #7

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

Safari is much bigger problem than Edge/IE. No hope for WebM in Safari. WebM for Edge is in development.

This is about an image format not a video format, so you probably mean WebP. WebP isn't supported in Firefox, Safari or IE, so it's not like Safari is the lone browser blocking new image formats.

Re: FLIF – Free Lossless Image Format

#18

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

Probably the best way to get this implemented is to encourage people to do the "polyfill"(+) solution of rendering to canvases. Browser implementers tend to follow actual usage, so the more widespread it is the more you can argue fait accompli.

(+) Does this share etymology with Polyfilla?

Re: FLIF – Free Lossless Image Format

#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...

Re: FLIF – Free Lossless Image Format

#20
post #11
post #6

Earlier quoted context omitted.

So you would need to load up the JS decompressor every single time you load a webpage? Or is there another way to do it efficiently ?

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.
Post reply on HN