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

161–170 of 254 posts

Re: FLIF – Free Lossless Image Format

#161

Post by eru »

Dylan16807 wrote: post #126
QasimK wrote: post #120

Earlier quoted context omitted.

How is it possible to have one-way only lossless compression?

Decompressing and recompressing a zip gives a lossless copy of the actual data , but there's no way to reconstruct the same exact zip you started with. The same thing can be done with image data. For something like jpeg you can keep the coefficients but store them in a more compact form. For what it's worth JPEG XL claims that it's 'reversible', but I'm not sure if that means you get your original jpeg back, byte for…

If you can get all the pixels back exactly, getting the original jpeg back would only require a very small amount of extra data.

But it might be more hassle than it's worth it to create the code and algorithms to do so.

Re: FLIF – Free Lossless Image Format

#162

Post by spider-mario »

BurningCycles wrote: post #117
setr wrote: post #111

Earlier quoted context omitted.

I'm assuming this is bidirectional? You can go back from XL to jpeg losslessly as well? If thats the case, I'm having trouble imagining a scenario where you're not correct; it'd be an utterly painless upgrade path

>You can go back from XL to jpeg losslessly as well I don't think so, but I don't quite see the point unless you are thinking of using it as a way to archive jpeg's, but in that case there are programs specifically for that, like PackJPG, Lepton etc.

JPEG XL integrates https://github.com/google/brunsli , and when used in that mode, you can go back to the original JPEG file in a bit-exact way.

There is also a mode that only preserves the JPEG image data.

Re: FLIF – Free Lossless Image Format

#163

Post by GoblinSlayer »

qwerty456127 wrote: post #131
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…

> It'd be lovely to have photos / screenshots / gifs all able to share a common format. Given the way GIF is used nowadays the only reason it exists is it let's you put a video on the most of the places where you are only allowed to put pictures. For some weird reason many of such websites still won't let you upload an MP4 file despite they auto-convert the gifs you upload to MP4/AVC. From the technical point of view…

Spinners are nothing but energy drain anyway. If there's no progress, spinner won't stop.

Re: FLIF – Free Lossless Image Format

#164

Post by adev_ »

DagAgren wrote: post #158
adev_ wrote: post #152

Earlier quoted context omitted.

> With the reference encoder licensed under LGPLv3, I doubt any browser team will be able to incorporate this work into their product. I'm gonna make enemies.... That's FUD and BSD bullshit. LGPL is not GPL. You can link what the fuck you want to a LGPL library included your proprietary code as long as you link dynamically. Gtk+ uses LGPL, GLib, uses LGPL, GNOME use LGPL, Qt uses LGPL, Cairo uses LGPL and millions of…

LGPL is incompatible with signed executables, which locks it out of anything distributed through an app store, which is a lot of software these days.

> LGPL is incompatible with signed executables

Do you have a source for that ?

Re: FLIF – Free Lossless Image Format

#165

Post by floatingatoll »

adev_ wrote: post #164
DagAgren wrote: post #158

Earlier quoted context omitted.

LGPL is incompatible with signed executables, which locks it out of anything distributed through an app store, which is a lot of software these days.

> LGPL is incompatible with signed executables Do you have a source for that ?

HN seems to have discussed this back in 2012: https://news.ycombinator.com/item?id=4789784

Re: FLIF – Free Lossless Image Format

#166

Post by CamperBob2 »

DagAgren wrote: post #158
adev_ wrote: post #152

Earlier quoted context omitted.

> With the reference encoder licensed under LGPLv3, I doubt any browser team will be able to incorporate this work into their product. I'm gonna make enemies.... That's FUD and BSD bullshit. LGPL is not GPL. You can link what the fuck you want to a LGPL library included your proprietary code as long as you link dynamically. Gtk+ uses LGPL, GLib, uses LGPL, GNOME use LGPL, Qt uses LGPL, Cairo uses LGPL and millions of…

LGPL is incompatible with signed executables, which locks it out of anything distributed through an app store, which is a lot of software these days.

Do signed executables fail to load unsigned DLLs?

Re: FLIF – Free Lossless Image Format

#167

Post by martin-adams »

It sure looks impressive. I think it's important to remember that comparing it to a lossy format will show it's disadvantages. For example on this demo:

https://uprootlabs.github.io/poly-flif/

If you compare with "same size JPG" and set the truncation to 80%, JPG appears to win out in terms of clarity of the image.

Re: FLIF – Free Lossless Image Format

#168

Post by maximegarcia »

flir wrote: post #144
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).

Not necessarily, the decoding can be stopped once you get enough usable information in regards to the usage of the image (display size ...) with the same source image. That's neat!

See the responsive part in https://flif.info/example.html

We can imagine decoding taking into account battery save mode, bandwidth save mode...

Re: FLIF – Free Lossless Image Format

#169

Post by GoblinSlayer »

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…

Image size won't reduce anyway. People will keep uploading images of the maximum allowed size, just in better quality.
Post reply on HN