Live data from Hacker News

FLIF – Free Lossless Image Format

flif.info

111–120 of 254 posts

Re: FLIF – Free Lossless Image Format

#111
post #82

Earlier quoted context omitted.

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

Re: FLIF – Free Lossless Image Format

#112
post #30
post #15

It looks like the the creator (Jon Sneyers) has since (2019) made another image format more focused on the lossy compression, FUIF[0], which itself has been subsumed by the JPEG XL format[1]. I hope the "JPEG" branding doesn't make folks think that JPEG XL isn't also a lossless format! [0] https://github.com/cloudinary/fuif [1] https://jpeg.org/jpegxl/index.html

JPEG XL is either lossy compression for large pictures, or something named by people who suck at branding.

And AVIF was that weird video format before mp4 became common everywere, right? /s

Re: FLIF – Free Lossless Image Format

#113
post #69

The upcoming, ubiquitous next gen codec, JPEG XR is heavily influenced by FLIF and is co-created by it's founder.

You mean JPEG XL. JPEG XR is an older codec based on Microsoft's HD Photo / Windows Media Photo. https://en.wikipedia.org/wiki/JPEG_XR

Correct.

Re: FLIF – Free Lossless Image Format

#115
post #39
post #34

Not a nice idea to do reference implementation in C++ instead of C!

One can use C++ in radically different ways. I would appreciate a reference implementation in Rust. Or, if not intended for immediate linking, in something like OCaml or ATS. Clarity and correctness are important in a reference implementation, and they are harder to achieve using C.

Best practices and rules in C++ are changing on a daily basis as the language is still evolving. On the other hand, C is much more readable for many programmers and researchers even with a little programming experience. Moreover, C is more portable and helps the reference implementation be quickly adapted for production or being used by the other compatible languages.

Re: FLIF – Free Lossless Image Format

#116
post #100

Earlier quoted context omitted.

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)

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

Re: FLIF – Free Lossless Image Format

#117
post #111

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

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

Re: FLIF – Free Lossless Image Format

#118

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?

Yes. If you examine PNG format, it actually uses pixels around a pixel to predict its value and compress the difference, which is much closer to 0 values. It actually uses zlib to compress just like gzip.

Re: FLIF – Free Lossless Image Format

#119

Isn't making it LGPL a problem? That means anything that touches it becomes LGPL, right?

Firstly, it's not a "problem" when code is released under the GPL. In many cases this is the best way to protect user freedom. Secondly, this is the Lesser GPL, which means that only modifications to the FLIF implementation itself have to be free. It can still be linked in proprietary programs as long as they don't make any modifications.

It can be linked in proprietary programs even if they do make modifications, they just need to release the modified source code (of the LGPL library). The trickier obstacle is that it is required to be able to replace the LGPL library with another version in the proprietary program. I.e. the LGPL library must be dynamically linked, or the linkable compiled object code for the rest of the proprietary program must be provided so the program can be relinked statically.

Re: FLIF – Free Lossless Image Format

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

How is it possible to have one-way only lossless compression?
Post reply on HN