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

91–100 of 254 posts

Re: FLIF – Free Lossless Image Format

#91

Post by BurningCycles »

rjvs wrote: post #82
BurningCycles wrote: post #78

Earlier quoted context omitted.

>Interesting. Where have you seen that adoption will be swifter with JPEG XL instead of, say, AV1/AVIF? Well, it's not finalized as of yet (though it is imminent), so rate of adoption is just pure guesswork at this stage. However, things I deem necessary for a new image codec to become the next 'de facto' standard are: royalty free major improvements over the current de facto standards Both AVIF and Jpeg XL tick thes…

So you're suggesting that the advantage JPEG XL has is that it will compress existing JPEGs better than FLIF or AVIF?

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/lossless compression overall.

Re: FLIF – Free Lossless Image Format

#92

Post by yjftsjthsd-h »

kccqzy wrote: post #89
bawolff wrote: post #41

The very obvious thing missing from the site is decode and encode benchmarks. Its very context dependent but if it had a long decode time, that could outweigh the bandwidth savings.

That's exactly what I thought. About ten years everyone is rushing to distribute large downloads in xz format. These days some have started to move away from it just because how slow it is to compress and decompress.

That's part of the benefit of zstd, as I understand it; near-xz compression ratios but much faster.

Re: FLIF – Free Lossless Image Format

#94

Post by mindslight »

colejohnson66 wrote: post #85
mindslight wrote: post #29

I use this to store archives of scanned documents. The last thing I want is to scan something only to later find some subtle image artifact corruption (remember that case of copy machines modifying numbers by swapping glyphs?). I store checksums and a static flif binary along with the archive. It's definitely overkill, but a huge win compared to stacks of paper sitting around. My intuition was informed by choosing FL…

The issue with copy machines modifying glyphs isn’t a problem with all algorithms; Really, only that one. Instead of just discarding data like a lossy algorithm, it would notice similar sections of the image and make them the same. Also, why not PNG?

Yeah, I'll admit that specific example wasn't the most relevant. Really I just want to be able to scan papers and then be confident enough to destroy them without having to scrutinize the output. Rather than committing to specific post-processing I settled on just keeping full masters of the 300dpi greyscale. Even at 5M/page, that's just 100GB for 20k pages.

I don't think PNG provided meaningful compression, due to the greyscale. If FLIF didn't exist, I certainly could have used PNG, for being nicer than PGM. But using FLIF seemed like a small compromise to pay for going lossless.

JPEG would have sufficed, but JPEG artifacts have always bugged me. I also considered JPEG2000 for a bit, which left me with a concern of how stable/future-proof are the actual implementations. Lossless is bit-perfect, so that concern is alleviated.

Re: FLIF – Free Lossless Image Format

#96

Post by labster »

frandroid wrote: post #95
octorian wrote: post #93

I'd be interested in a format that can replace TIFF, without the files being quite so enormous. However, it seems like all the FLIF tools are assuming you're coming from PNG-land.

In what way has PNG not already replaced TIFF?

TIFF is a container format that allows you to add other features into the file. A good example of this is GeoTIFF, which is like a grid data file that also happens to be viewable as an image.

Re: FLIF – Free Lossless Image Format

#97

Post by jhoechtl »

kalleboo wrote: post #71
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…

What it will take for something to overthrow JPEG is for both Google and Apple to adopt it. If Android, Chrome, iOS, macOS and Safari all support it (and the phones shoot in it natively like the iPhone does with HEIF right now), it will take over.

Think of it Google favoring sites with AVIF, JPEG XL, whatever they settle on in their page rank? Within half a year 80% of the web sites will have converted.

Re: FLIF – Free Lossless Image Format

#98

Post by toastal »

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.

Re: FLIF – Free Lossless Image Format

#100

Post by loeg »

yjftsjthsd-h wrote: post #92
kccqzy wrote: post #89

Earlier quoted context omitted.

That's exactly what I thought. About ten years everyone is rushing to distribute large downloads in xz format. These days some have started to move away from it just because how slow it is to compress and decompress.

That's part of the benefit of zstd, as I understand it; near-xz compression ratios but much faster.

Compression is only mildly faster or on par with xz, but decompression is (at similar ratios) vastly faster. Which really helps consumers of compressed blobs.
Post reply on HN