FLIF – Free Lossless Image Format • Hacker News Board

Re: FLIF – Free Lossless Image Format

#151

Post by account42 » Fri, Feb 07, 2020, 10:22 AM UTC

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…

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

I don't think getting the same JPEG is the goal here but getting a JPEG that decodes to the same image data.

Re: FLIF – Free Lossless Image Format

#152

Post by adev_ » Fri, Feb 07, 2020, 10:28 AM UTC

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…

> 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 applications link into these ones without problems.

I'm not aware of any case in history where a company got attacked, or frightened to use a LGPL library in their codebase.

It would be good to stop the FUD excepted if you need to feed your lawyer.

Re: FLIF – Free Lossless Image Format

#153

Post by eln1 » Fri, Feb 07, 2020, 10:41 AM UTC

vardump wrote: post #109

> FLIF is based on MANIAC compression. MANIAC (Meta-Adaptive Near-zero Integer Arithmetic Coding) is an algorithm for entropy coding developed by Jon Sneyers and Pieter Wuille. It is a variant of CABAC (context-adaptive binary arithmetic coding), where instead of using a multi-dimensional array of quantized local image information, the contexts are nodes of decision trees which are dynamically learned at encode time.…

Jon Sneyers is currently working on JPEG XL, which uses ANS: https://www.spiedigitallibrary.org/conference-proceedings-of...

Re: FLIF – Free Lossless Image Format

#154

Post by ubercow13 » Fri, Feb 07, 2020, 10:51 AM UTC

QasimK wrote: post #120

BurningCycles wrote: post #117

Earlier quoted context omitted.

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

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

Is it possible to get a JPEG back without any loss when recompressing a JPEG to another JPEG (after discarding the original, ie JPEG -> bitmap -> JPEG)?

Re: FLIF – Free Lossless Image Format

#155

Post by londons_explore » Fri, Feb 07, 2020, 10:52 AM UTC

Chromium has a pluggable interface for image formats. Add it to the Chromium source tree, and you get support in Opera, Chrome, and Edge.

Simply search "webp" in the codebase, and you can add another format like that.

I wonder if the Chromium developers would accept a patch for it?

Re: FLIF – Free Lossless Image Format

#156

Post by DagAgren » Fri, Feb 07, 2020, 10:56 AM UTC

nine_k wrote: post #43

parvenu74 wrote: post #13

I want to root for it but I think the LGPL license ruins it as long as there are BSD or MIT licenses alternatives that are good enough. Firefox might implement it but I think there’s zero change that Chromium or Safari add support.

I think that LGPL for the encoder is exactly the right choice. A format's strength is in uniform support; taking a MIT-licenced encoder and making an improved incompatible format won't be great for end users.

Is it better that no tools will actually be able to export the format?

Also, a GPL-licensed encoder will in no way stop incompatible extensions.

Re: FLIF – Free Lossless Image Format

#157

Post by ubercow13 » Fri, Feb 07, 2020, 10:56 AM UTC

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…

With the amount of images readily available on the internet with easily visible JPEG compression artifacts, and sometimes the difficulty of finding images without such, I would say there is still quite a lot to gain from better image formats.

Re: FLIF – Free Lossless Image Format

#158

Post by DagAgren » Fri, Feb 07, 2020, 10:58 AM UTC

adev_ wrote: post #152

floatingatoll wrote: post #7

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

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

Re: FLIF – Free Lossless Image Format

#159

Post by theon144 » Fri, Feb 07, 2020, 11:03 AM UTC

DagAgren wrote: post #156

nine_k wrote: post #43

Earlier quoted context omitted.

I think that LGPL for the encoder is exactly the right choice. A format's strength is in uniform support; taking a MIT-licenced encoder and making an improved incompatible format won't be great for end users.

Is it better that no tools will actually be able to export the format? Also, a GPL-licensed encoder will in no way stop incompatible extensions.

Uh, LGPL explicitly doesn't prevent even proprietary software from using the encoder?

Re: FLIF – Free Lossless Image Format

#160

Post by ubercow13 » Fri, Feb 07, 2020, 11:08 AM UTC

setr wrote: post #111

BurningCycles wrote: post #91

Earlier quoted context omitted.

Yes, it losslessly recompresses existing jpeg's into the jpeg XL format, while also making the files ~20% smaller, key point being lossless. Thus it is the 'perfect' upgrade path from jpeg which is the current lossy standard, as you will get better compression and no loss in quality when shifting to Jpeg XL. This being a 'killer feature' of course relies on Jpeg XL being very competitive with AVIF in terms of lossy/l…

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

Looks like yes [1]

>A lightweight lossless conversion process back to JPEG ensures compatibility with existing JPEG-only clients such as older generation phones and browsers. Thus it is easy to migrate to JPEG XL, because servers can store a single JPEG XL file to serve both JPEG and JPEG XL clients.

[1] https://jpeg.org/jpegxl/index.html