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

201–210 of 254 posts

Re: FLIF – Free Lossless Image Format

#201

Post by gardaani »

TheRealPomax wrote: post #198
supportlocal4h wrote: post #190

Earlier quoted context omitted.

Progressive photos always irritate me. The photo comes on my screen all blurry and out of focus and I'm disappointed that the moment I thought I had captured didn't turn out. Then, 3 seconds later, the picture changes and gets slightly better. Then I'm hopeful, but disappointed again. Then i think, "maybe it's not loaded yet", so i wait and hope. Then 2 seconds later it changes again. Is it done? Is it loaded now? Wi…

On the other hand, it also doesn't constantly change the DOM, moving you across the page because images above what you're reading are getting swapped in and now you're looking at the paragraph above the one you were reading. and again. oh, and again. and-

Fixing jumping pages doesn't require progressive image formats. All browsers soon support setting default aspect ratio for all images: https://twitter.com/jensimmons/status/1220114427690856453

Re: FLIF – Free Lossless Image Format

#202

Post by floatingatoll »

adev_ wrote: post #187
floatingatoll wrote: post #165

Earlier quoted context omitted.

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

It does not seem to do consensus to me, just speculations. And even if it would be a consensus, there is way to link statically with LGPL and still respect the license.

Do you have a source for that?

Could you please provide supporting evidence for your view that is a consensus? Where is the documentation explaining your “static link” proposal and why it’s been endorsed by lawyers as a permitted approach? What was the response from the GPL team when they were asked to comment on this circumvention of their license? Will they be patching GPLv3 to correct it?

Re: FLIF – Free Lossless Image Format

#203

Post by pier25 »

toastal wrote: post #98
pier25 wrote: post #22

They have a polyfill for browsers: https://github.com/UprootLabs/poly-flif It weights 77kB gzipped which is a no-no in my book. Jesus, my current Mithril SPA weights 37kB gzipped. Not the JS bundle, the complete application.

There's a lot of images online that are 1MB. If you're, say, displaying a gallery of photos, you may have saved more in bandwidth using this library plus several smaller images.

It's only the bandwidth. CPU can also be a factor.

Re: FLIF – Free Lossless Image Format

#204

Post by janwas »

eru wrote: post #161
Dylan16807 wrote: post #126

Earlier quoted context omitted.

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.

Hi, we indeed support byte for byte reconstruction of the original JPEG codestream.

Re: FLIF – Free Lossless Image Format

#205

Post by janwas »

edflsafoiewq wrote: post #132
BurningCycles wrote: post #55

Earlier quoted context omitted.

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

It sounds interesting, although my initial impression is that it sound like it will suffer from the same daunting complexity that afflicted JPEG 2000.

Good news: the reference software (http://gitlab.com/wg1/jpeg-xl) can decode about 50 Megapixels/s on a single Skylake core, with 3.1-3.7x speedup on 4 cores.

Encoding throughput is configurable from ~1 MP/s to about 50 per core. That's somewhat slower than JPEG, but can be faster with multiple cores.

Re: FLIF – Free Lossless Image Format

#206

Post by janwas »

andrius4669 wrote: post #175
jiofih wrote: post #121

Earlier quoted context omitted.

Is JPEG XL also suited to replace PNG like FLIF?

yeah. it's partially based on https://github.com/cloudinary/fuif so if you use that part of JPEG XL you'll get something similar out of it.

Yes indeed, for the lossless mode (based on tech by the same author) we're seeing about 45-82% of GIF size, and 60-80% of (A)PNG depending on content.

Re: FLIF – Free Lossless Image Format

#207

Post by terrelln »

loeg wrote: post #116
yjftsjthsd-h wrote: post #106

Earlier quoted context omitted.

Yeah, that's a useful distinction. So it's excellent for ex. packages (hence https://www.archlinux.org/news/now-using-zstandard-instead-o... ), but iffy for write-once-read-hopefully-never backups. (Although I've heard it suggested that this might flip again the moment you start test-restoring backups regularly)

Agreed. I think I'd take zstd over xz for WORN backups anyway, just because it's pretty reliable at detecting stream corruption. (Then again, I suggest generating par2 or other FEC against your compressed backups so that's not a problem.)

Zstd has a 32-bit checksum over the uncompressed data, which is enabled by default on the CLI.

Re: FLIF – Free Lossless Image Format

#208

Post by jonsneyers »

FLIF author here. I have been working on FUIF and JPEG XL the past two years. FUIF is based on FLIF but is better at lossy. JPEG XL is a combination of Google's PIK (~VarDCT mode) and FUIF (~Modular mode). You'll be able to mix both codecs for a single image, e.g. VarDCT for the photo parts, Modular for the non-photo parts and to encode the DC (1:8) in a super-progressive way.

I'm very excited about JPEG XL, it's a great codec that has all the technical ingredients to replace JPEG, PNG and GIF. We are close to finalizing the bitstream and standardizing it (ISO/IEC 18181). Now let's hope it will get adoption!

Re: FLIF – Free Lossless Image Format

#209

Post by adev_ »

floatingatoll wrote: post #202
adev_ wrote: post #187

Earlier quoted context omitted.

It does not seem to do consensus to me, just speculations. And even if it would be a consensus, there is way to link statically with LGPL and still respect the license.

Do you have a source for that? Could you please provide supporting evidence for your view that is a consensus? Where is the documentation explaining your “static link” proposal and why it’s been endorsed by lawyers as a permitted approach? What was the response from the GPL team when they were asked to comment on this circumvention of their license? Will they be patching GPLv3 to correct it?

> Could you please provide supporting evidence for your view that is a consensus?

Consensus is what is admitted by most actors, specially including the main interested actor: The FSF and the GNU project. And I do not remember reading any communication of the FSF or the GNU project saying it is forbidden.

Currently the license text is very explicit about what you can do and not do if you link statically.

> 0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.

Which means: You have to provide a way for your user to recompile statically their application with a new version of the library. Meaning, you have to provide a tarball with your object.o files if someone ask for it.

It is even documented explicitly by the FSF:

https://softwareengineering.stackexchange.com/questions/3127...

https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDyn...

Re: FLIF – Free Lossless Image Format

#210

Post by nathan_long »

thaumasiotes wrote: post #123
Scaevolus wrote: post #79

Earlier quoted context omitted.

This presentation covers why AVIF isn't a great replacement for JPEG-- mostly that it's slow, complicated, and lacks a progressive mode. https://www.slideshare.net/cloudinarymarketing/imagecon-2019...

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

Imagine this: you set your browser to download only the first N bytes of each image, showing you a decent preview. If you want more detail on a particular image, you tap it, and the browser requests the next N bytes (or the rest of the file, if you prefer).

And to enable this, the site only needed to create one high-resolution image.

Seems like a victory for loading speeds, for low-bandwidth, and for content creation.

I think FLIF looks incredible.

Post reply on HN