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 254 posts

Re: FLIF – Free Lossless Image Format

#141

Post by lisper »

Dylan16807 wrote: post #139
lisper wrote: post #138

Earlier quoted context omitted.

> A sufficiently bad lossy algorithm can be worse than an algorithm like PNG in every single case. Well, yeah, obviously if you want to shoot yourself in the foot that is always possible. But for any lossless algorithm it is trivial to derive a corresponding lossy algorithm that will compress better than the lossless one.

> derive a corresponding lossy algorithm that will compress better than the lossless one Which is a completely different problem from taking a fixed lossy algorithm and trying to beat it.

Fair enough. Nonetheless, a lossy compression algorithm by definition produces fewer possible outputs than possible inputs. A lossless compression algorithm, again by definition, produces exactly as many different outputs as there are possible inputs. Therefore, on average, unless the lossless algorithm has a perverse encoding that uses more bits than necessary to encode the possible outputs, no lossless algorithm can beat it on average. It is of course possible that a lossless algorithm might beat a lossy one on some select inputs. It's even possible that those inputs are the ones you are interested in, but in that case you are using the wrong lossy algorithm.

Re: FLIF – Free Lossless Image Format

#142

Post by jillesvangurp »

yason wrote: post #140

Yet, I think it's really hard to change what has stuck. The gains have to be enormous to warrant the hassle of trying to keep publishing in and supporting a new image format until it just works for everyone. The reason we have PNG and JPEG is that they are, all in all, more than good enough. Yes, the dreaded "good enough" argument surfaces again stronger than ever. They are also easy to understand, i.e. use JPEG for…

The reason we have jpeg is because png is not good enough for photos and people prefer the lossy compression of jpeg over using png. The reason other lossy formats are struggling is because they are still lossy. This promises to basically be good enough for just about anything. That sounds like a big promise but if true, there's very little stopping major browser implementing support for this. I'd say progressive decompression sounds like a nice feature to have for photo websites.

Compression is still majorly important on mobile. Mobile coverage is mostly not great except maybe in bigger cities where you get to share the coverage with millions of others. Also mobile providers still throttle connections, bill per GB, etc. So, it matters. E.g. Instagram adopting this could be a big deal. All the major companies are looking to cut bandwidth cost. That's also what's driving progress for video codecs. With 4K and 8K screens becoming more common, jpeg is maybe not good enough anymore.

Re: FLIF – Free Lossless Image Format

#144

Post by flir »

perenzo wrote: post #143

Introducing better compression of images and animations would be another small step fighting climate change. Less data, less transfer, less energy consumption! https://www.dw.com/en/is-netflix-bad-for-the-environment-how...

But more energy required to decompress, surely? (Not counting the compression step because I assume that's marginal at scale).

Re: FLIF – Free Lossless Image Format

#145

Post by mrob »

jstummbillig wrote: post #130
thaumasiotes wrote: post #123

Earlier quoted context omitted.

Why would the lack of a progressive mode matter? How is a progressive mode better than a "loading..." spinner?

Progressive mode is better than a loading spinner in the same way that PWAs are better than a loading spinner: By getting mostly usable content in as little time as possible to the user you decrease perceived wait, you decrease time to interactive and you increase perceived loading speed (even though time to full load might be the same or slightly increased).

In the common case that you don't actually care about the picture, you decrease actual wait, not just perceived. Progressive mode lets you ignore it before it's fully loaded.

Re: FLIF – Free Lossless Image Format

#146

Post by floatingatoll »

Polylactic_acid wrote: post #54
sjwright wrote: post #51

Earlier quoted context omitted.

How would the evaluation of any codec be hampered by any open source license?

Not even the most restrictive copyleft license hampers evaluation. You are literally free to do whatever you want with the program on your own hardware. Its only when you start redistributing that the license kicks in.

What degree of rewriting would be necessary to neutralize the LGPLv3 license restrictions? Would I be sued if I used the same logic flow but handcrafted every statement from a flow diagram generated from the source code?

If I study the source and then make a single change to my own algorithm to incorporate the secret sauce in order to test its efficacy using my existing test suites, have I infected my own codebase with LPGLv3?

How can I test this code in the real world with real users if I’m not allowed to redistribute it? Would I be required to pay users as contractors to neutralize the redistribution objection?

Etc, etc.

EDIT: Neutralizing LGPLv3 would be necessary to combine this code with GPLv2 code and many other OSF-approved open source licenses, which is why that particular line of reasoning is interesting to me.

Re: FLIF – Free Lossless Image Format

#148

Post by marton78 »

BurningCycles wrote: post #55
jjcm wrote: post #47

Always cool to see new visual compression libraries hit the scene. That said I think the hardest part isn't the math of it, but the adoption of it. Likely the format with the best chance of overthrowing the jpg/gif/png incumbents is AVIF. Since it's based on AV1, you'd get hardware acceleration for decoding/encoding once it starts becoming a standard, and browser support will be trivial to add once AV1 has wide suppo…

>Likely the format with the best chance of overthrowing the jpg/gif/png incumbents is AVIF I used to think the same as well, however I now think Jpeg XL is poised to be the 'winner' among next gen image codecs. It's royalty free, great lossy and lossless compression which is said to beat the competition, as well as providing a perfect upgrade path for existing jpeg's as it can losslessly recompress them into the jpeg…

JPEG XL is a terrible name for something that claims to produce extra small results.

Re: FLIF – Free Lossless Image Format

#149

Post by GoblinSlayer »

jstummbillig wrote: post #130
thaumasiotes wrote: post #123

Earlier quoted context omitted.

Why would the lack of a progressive mode matter? How is a progressive mode better than a "loading..." spinner?

Progressive mode is better than a loading spinner in the same way that PWAs are better than a loading spinner: By getting mostly usable content in as little time as possible to the user you decrease perceived wait, you decrease time to interactive and you increase perceived loading speed (even though time to full load might be the same or slightly increased).

Did you confuse terminology? Web progressive is sort of an antonym to graphics progressive.

Re: FLIF – Free Lossless Image Format

#150

Post by littlestymaar »

floatingatoll wrote: post #7
ronyfadel wrote: post #5

Before Apple/Google/Mozilla adopt in their browsers, I doubt this will get any traction.

With the reference encoder licensed under LGPLv3, I doubt any browser team will be able to incorporate this work into their product. They would need to do a full clean room reimplementation simply to study it (since GPLv3 seems unacceptable to them, and LGPLv3 can’t coexist with GPLv2, and so forth and so on). It’s really unfortunate that the FLIF team chose such a restrictive license :( EDIT: Their reference JS poly…

You're confusing the encoder and decoder: a browser only needs an encoder and FLIF provides a Apache-licenced one.
Post reply on HN