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

101–110 of 254 posts

Re: FLIF – Free Lossless Image Format

#101

Post by emptybits »

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?

BTW, I know this because I recently embarked on some photo import/edit/management scripts and wondered the same thing you did: "Why isn't PNG a thing yet??" There are reasons. A few, from minor to major IMO:

TIFF acknowledges EXIF and IPTC as first class data. PNG added EXIF data as an official extension a couple of years ago and I know ExifTool does support it but I'd want to check all applications in a workflow for import/edit/export support before trusting it.

TIFF supports multiple pages (images) per file and also multilayer images (ala photo-editing).

TIFF supports various colour spaces like CMYK and LAB. AFAIK, PNG only supports RGB/RGBA so for image or print professionals, that could be a non-starter.

So I get why PNG can't warm photographers' hearts yet. Witness still the most common workflows: RAW->TIFF & RAW->JPEG.

Re: FLIF – Free Lossless Image Format

#104

Post by chime »

aidenn0 wrote: post #102

Could you end up with a lossy format just by truncating a FLIF? The Adam7 comparison shows it as looking reasonable at about 5% transfer.

I think yes. From their site: https://flif.info/responsive.html

> A FLIF image can be loaded in different ‘variations’ from the same source file, by loading the file only partially. This makes it a very appropriate file format for responsive web design. Since there is only one file, the browser can start downloading the beginning of that file immediately, even before it knows exactly how much detail will be needed. The download or file read operations can be stopped as soon as sufficient detail is available, and if needed, it can be resumed when for whatever reason more detail is needed — e.g. the user zooms in or decides to print the page.

Re: FLIF – Free Lossless Image Format

#105

Post by kragen »

lisper wrote: post #50
kragen wrote: post #24

Earlier quoted context omitted.

It would be reasonable to interpret the shorter boast as making the very surprising claim that it beats anything else, including lossy JPEG, in all categories of performance, including compression ratio. As it turns out, they don't intend to claim that, because it's not true. It's probably impossible for a lossless file format to do that, even for commonly occurring images. (It's certainly possible for a lossless ima…

> It's probably impossible for a lossless file format to do that, even for commonly occurring images. It's actually provably impossible using a simple counting argument. A lossy algorithm can conflate two non-identical images and encode them the same way while a lossless algorithm can't, so on average the output of a lossless algorithm is necessarily larger than a lossy one because it has to encode more possible outp…

Yes, of course it's impossible to losslessly compress all possible images by even a single bit. But how predictable is the content of typical images? How much structure do they have? They certainly have a lot more structure than PNG or even JPEG exploits. Some of the “loss” of lossy JPEG is just random sensor noise, which places a lower bound on the size of a losslessly compressed image, but we have no idea how much.

Re: FLIF – Free Lossless Image Format

#106

Post by yjftsjthsd-h »

loeg wrote: post #100
yjftsjthsd-h wrote: post #92

Earlier quoted context omitted.

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.

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)

Re: FLIF – Free Lossless Image Format

#107

Post by canistel »

Sorry to ask a very ametuerish question, but how is lossless compression of an image different from regular run of the mill compression (zip, 7z)? Is there any sort of underlying pattern or feature which is unique to image data that is leveraged/exploited for lossless image compression?

Re: FLIF – Free Lossless Image Format

#108

Post by lisper »

kragen wrote: post #105
lisper wrote: post #50

Earlier quoted context omitted.

> It's probably impossible for a lossless file format to do that, even for commonly occurring images. It's actually provably impossible using a simple counting argument. A lossy algorithm can conflate two non-identical images and encode them the same way while a lossless algorithm can't, so on average the output of a lossless algorithm is necessarily larger than a lossy one because it has to encode more possible outp…

Yes, of course it's impossible to losslessly compress all possible images by even a single bit. But how predictable is the content of typical images? How much structure do they have? They certainly have a lot more structure than PNG or even JPEG exploits. Some of the “loss” of lossy JPEG is just random sensor noise, which places a lower bound on the size of a losslessly compressed image, but we have no idea how much.

Doesn't matter. Whatever you do to compress losslessly you can always do better if you're allowed to discard information. And the structure is part of the reason. For lossless compression you have to keep all the noise, all the invisible details. With lossy compression you're allowed to discard all that.

Re: FLIF – Free Lossless Image Format

#109

Post by vardump »

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

I wonder if tANS [0] could be used instead of arithmetic coding for (presumably) higher performance. Although I guess the authors must be aware of ANS. Would be interesting to hear why it wasn't used instead.

[0]: Tabled asymmetric numeral systems https://en.wikipedia.org/wiki/Asymmetric_numeral_systems#tAN...

Re: FLIF – Free Lossless Image Format

#110

Post by thdrdt »

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…

Exactly what you are saying: FLIF is not new (2015) but is still not adopted in any browser I know.

I also believe this was due to some license choices in the past.

But in this time of responsive websites it is a great format! Just download the amount of pixels you need to form a sharp image and then skip loading the rest.

I really hope this becomes mainstream one day.

Post reply on HN