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

81–90 of 153 posts

Re: FLIF – Free Lossless Image Format

#81

Post by teh_klev »

formula1 wrote: post #79
teh_klev wrote: post #76

Earlier quoted context omitted.

Not trying to be obtuse, but that's just a subjective measure of how quick or not their algo is. It doesn't address (nor in the linked HN discussion) how efficient it is in terms of burning up CPU and battery.

If it takes a long time, it probably means that there is a lot to calculate. If theres a lot to calculate, probably means the cpu is running full speed to get through it

Oh sure, I understand that, but many compression articles often focus just on compression ratios (such as this one seems to do), but have no mention of the tradeoffs to obtain these results, or compare themselves against existing and well establish algorithms.

That was the point of my post.

Re: FLIF – Free Lossless Image Format

#83

Post by delinka »

monkmartinez wrote: post #77
tomtheguvnor wrote: post #75

Apparently it relies on a novel new "middle out" compression algorithm.

Here is the paper[1] regarding the "middle out" or "tip to tip efficiency" algorithm. [1] http://www.scribd.com/doc/228831637/Optimal-Tip-to-Tip-Effic...

"Middle out" is not "tip-to-tip efficiency." Though they were indeed invented (discovered?) by the same team at approximately the same time, and may also be linked (depending on one's scientific, mathematical and/or philosophical definition of 'linked') they are independent algorithms solving radically different problems.

Re: FLIF – Free Lossless Image Format

#84

Post by formula1 »

teh_klev wrote: post #81
formula1 wrote: post #79

Earlier quoted context omitted.

If it takes a long time, it probably means that there is a lot to calculate. If theres a lot to calculate, probably means the cpu is running full speed to get through it

Oh sure, I understand that, but many compression articles often focus just on compression ratios (such as this one seems to do), but have no mention of the tradeoffs to obtain these results, or compare themselves against existing and well establish algorithms. That was the point of my post.

Ah, my intention radar was off. I assumed you were making an observation but didnt jump to the probable conclusion

Re: FLIF – Free Lossless Image Format

#85

Post by JoshTriplett »

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 control whether to load the rest of the image.

Re: FLIF – Free Lossless Image Format

#87

Post by mistercow »

matheweis wrote: post #86

I'm curious about patent/ licensing restrictions. From what I gather it is patent free and the implementation is GPLv3? Does this mean someone else could make a compatible encoder/decoder with a less restrictive license?

It's lgpl3, which is less restrictive than gpl3.

Re: FLIF – Free Lossless Image Format

#88

Post by joosters »

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…

It shouldn't be used to replace JPEGs, but PNG files are widely used and would be good candidates for FLIF files instead.

Also true for static GIFs, but presumably anyone still using them is not bothered about converting images to better formats.

Re: FLIF – Free Lossless Image Format

#90

Post by MyNameIsFred »

pjc50 wrote: post #18
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...

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: Pollyfilla Yes, I believe that's the idea.
Post reply on HN