36 ms·

FLIF – Free Lossless Image Format

691 points by scotteh 7y ago

sovok_x 7y ago
Checklist for how far it should go to be accepted format, applicable to JPEG XL too: - SIMD-optimised encoder/decoder for major programming languages; - stable photoshop and gimp import/export plugins, supporting layers, animation and transparency features; - metadata reading/writing library for major programming languages; - firefox and chrome integration at least.
SethTro 7y ago
The progressive loading video is great!
- Polylactic_acid 7y ago
  This is something I wish was used on the web. Imagine instead of creating a high compression image for use on a web page and then having a link for the full res one, you could just say "Load this image at 60%" and if users right click and save it would download the entire image.
Camas 7y ago
https://web.archive.org/web/20200207000006/https://flif.info/ https://web.archive.org/web/20200207000006/https://flif.info...
RcouF1uZ4gsC 7y ago
Seems really cool. It seems that the biggest gatekeepers for image formats are Apple and Google because of iPhone/Safari and Android/Chrome. Basically, if you want to be able to easily view the image on a mobile device or on the web, the format needs their blessing.
- taneq 7y ago
  They have a demo using a prototype browser polyfill so you could arguably use it right now at the cost of slightly higher CPU usage. Depending on your data connection it could even end up using less battery on mobile due to reduced radio usage.
- gtirloni 7y ago
  Well, Chromium is open source so it's open to anyone to implement it.
  - nine_k 7y ago
    Is it easy to get your PR merged if it introduces support for a new image format?
  - Polylactic_acid 7y ago
    Its about as useful as sending a politician an email. Technically the option exists but its not of much use.
ronyfadel 7y ago
Before Apple/Google/Mozilla adopt in their browsers, I doubt this will get any traction.
- floatingatoll 7y ago
  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 polyfill implementation is LGPLv3 as well, which may further harm adoption.
  - deleted 7y ago
    [deleted]
  - yellowapple 7y ago
    The decoder-only version of the reference implementation (libflif_dec) uses the Apache 2.0 license (specifically for this reason, I'd assume). Browsers shouldn't need to encode FLIF images very often, so decoder-only would be fine for that use case.
    - floatingatoll 7y ago
      Evaluating the efficacy of the new image codec is not possible using only a decoder. I was unable to find an APL2 JS polyfill decoder. Does one exist?
      - sjwright 7y ago
        How would the evaluation of any codec be hampered by any open source license?
        Polylactic_acid 7y ago
Latty 7y ago
The section "Works on any kind of image" is really misleading, as it mentions JPEG as a lossy format (alongside JPEG 2000) then says "FLIF beats anything else in all categories." It really needs a giant caveat saying "lossless". I mean, that's still great and impressive, but it clearly doesn't erase the need for a user to switch formats as a lossless format is still not suitable for end users a lot of the time. (It does have a lossy mode, detailed on another page, but they clearly show it doesn't have the same advantage over other formats there.)
- azinman2 7y ago
  It literally stands for "FLIF - Free Lossless Image Format", and the first sentence is "FLIF is a novel lossless image format which outperforms PNG, lossless WebP, lossless BPG, lossless JPEG2000, and lossless JPEG XR in terms of compression ratio." Seems like they're doing a pretty decent job at communication it's lossless to me.
  - kragen 7y ago
    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 image format to do that for images that have a lot of redundancy in a form that JPEG isn't sophisticated enough to recognize.)
    - lisper 7y ago
      > 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 outputs.
Camillo 7y ago
Looks great. What about decoding and encoding speed?
- MonadIsPronad 7y ago
  The TODO list mentions optimization, so probably not on par with the status quo yet, I'd guess.
foolrush 7y ago
Little mention of alpha encoding, something PNG absolutely botched. Unsurprising.
- mark-r 7y ago
  I've never noticed a problem with alpha in PNG, how did they botch it?
parvenu74 7y ago
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.
- CobrastanJorji 7y ago
  They could conceivably buy a different license from the author, if the author were to be interested in that, and if the author's the only contributor and didn't derive their code from othe LGPL code, etc, etc.
- MonadIsPronad 7y ago
  There's also an Apache 2 licenced decoder mentioned, perhaps with exactly this in mind...
  - not2b 7y ago
    Only the encoder is LGPL, the decoder is Apache, web browsers only need a decoder.
- nine_k 7y ago
  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.
  - DagAgren 7y ago
    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.
    - theon144 7y ago
      Uh, LGPL explicitly doesn't prevent even proprietary software from using the encoder?
tangm 7y ago
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 https://github.com/cloudinary/fuif [1] https://jpeg.org/jpegxl/index.html https://jpeg.org/jpegxl/index.html
- pnako 7y ago
  JPEG XL is either lossy compression for large pictures, or something named by people who suck at branding.
  - deleted 7y ago
    [deleted]
  - andrewzah 7y ago
    Made by the same folks who brought you JPEG 2000. /s
    - pmarreck 7y ago
      I was a fan/proponent of that! Whatever happened to wavelet compression?
      - loeg 7y ago
        Patents.
        ksec 7y ago
        Most of them had expired. Wavelet is something that looks good in theory but in practice couldn't beat the millions man hours work put into standard DCT.
  - Double_a_92 7y ago
    And AVIF was that weird video format before mp4 became common everywere, right? /s
MonadIsPronad 7y ago
Very cool, hoping to see more of this in the future. Good job team
pier25 7y ago
They have a polyfill for browsers: https://github.com/UprootLabs/poly-flif 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.
- hug 7y ago
  While weight is a factor in professional car racing, and while I've built a go-kart that is significantly lighter in weight than a professional racing car, it is not a particularly impressive achievement that I have managed to do so, and I wouldn't think to criticize a race team for the weight of their vehicle.
  - andrewzah 7y ago
    Good thing we’re discussing JavaScript library sizes and not cars in random contexts, then. 77kb gzipped is massive considering it’s only doing one thing. If I want my website to load in ~100 milliseconds or less (or even 1 second or less!), I absolutely do need to pay attention to all the libraries I add. I can and do criticize software developers for making hideously bloated websites because they don’t pay attention to what they add. Not only are a lot of modern websites wasteful, they’re painful or outright useless on slow mobile connections—not a problem for software developers on fibre networks, beefy dev machines, etc.
    - hug 7y ago
      So it turns out that the use-case for a polyfill of a 77KB image decoder isn't particular suited to a site you want to load in sub 100ms. Oddly, though, that's not the only usecase in the world, and there are circumstances where saving ~30% on every image load turns out to be significantly more efficient than not loading a 77KB JS library. In other news, I also chose to forgo adding a 15 lb. fuel pump to my go-kart, despite the fact that every NASCAR team in the world uses one, and my go-kart drives just fine. I should go tell the NASCAR teams that fuel pumps are a terrible idea. I clearly know something they don't.
dang 7y ago
Related from 2016: https://news.ycombinator.com/item?id=12626451 https://news.ycombinator.com/item?id=12626451 https://news.ycombinator.com/item?id=11238190 https://news.ycombinator.com/item?id=11238190 2015: https://news.ycombinator.com/item?id=10317790 https://news.ycombinator.com/item?id=10317790
The_rationalist 7y ago
The upcoming, ubiquitous next gen codec, JPEG XR is heavily influenced by FLIF and is co-created by it's founder.
- sjwright 7y ago
  No codec is “ubiquitous” until it is.
- re 7y ago
  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 https://en.wikipedia.org/wiki/JPEG_XR
  - The_rationalist 7y ago
    Correct.
mindslight 7y ago
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 FLAC for my music collection ~15 years ago, and that working out fantastically. If a better format does come along, or if I change my mind, I can always transcode.
- colejohnson66 7y ago
  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?
  - catalogia 7y ago
    > Also, why not PNG? The article claims 43% improvement over typical PNGs, if you have a lot of images that's pretty significant.
  - mindslight 7y ago
    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.
sd314 7y ago
Not a nice idea to do reference implementation in C++ instead of C!
- nine_k 7y ago
  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.
  - sd314 7y ago
    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.
    - adev_ 7y ago
      > Best practices and rules in C++ are changing on a daily basis as the language is still evolving. Yeah "daily", C++ standard evolves every 3 years minimum and most API are still C++11 meaning 9 years old. "Daily" right ? This is FUD. Without even mentioning that any C++lib can expose a C API.
bawolff 7y ago
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.
- kccqzy 7y ago
  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.
  - yjftsjthsd-h 7y ago
    That's part of the benefit of zstd, as I understand it; near-xz compression ratios but much faster.
    - loeg 7y ago
      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.
      - yjftsjthsd-h 7y ago
        Yeah, that's a useful distinction. So it's excellent for ex. packages (hence https://www.archlinux.org/news/now-using-zstandard-instead-of-xz-for-package-compression/ 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)
        loeg 7y ago
        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.)
sand500 7y ago
In terms of getting it into chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=539120 https://bugs.chromium.org/p/chromium/issues/detail?id=539120 > Keep in mind that the author of the FLIF works on the new FUIF (https://github.com/cloudinary/fuif https://github.com/cloudinary/fuif) which will be part of the JPEG XL. So, probably FLIF will be deprecated soon. And as far as JPEG XL is also based on Google PIX, there is a high probability that Google will support this new format in their Blink engine. https://jpeg.org/jpegxl/index.html https://jpeg.org/jpegxl/index.html
- markdog12 7y ago
  You can encode to JPEG XL here: https://libwebpjs.appspot.com/jpegxl/ https://libwebpjs.appspot.com/jpegxl/ (Compiled to WebAssembly, not by me)
- jiofih 7y ago
  Is JPEG XL also suited to replace PNG like FLIF?
  - andrius4669 7y ago
    yeah. it's partially based on https://github.com/cloudinary/fuif https://github.com/cloudinary/fuif so if you use that part of JPEG XL you'll get something similar out of it.
    - janwas 7y ago
      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.
      - JyrkiAlakuijala 7y ago
        Also other famous compression gurus, including Alex Rhatushnyak and Lode Vandevenne contributed to the lossless side of JPEG XL.
jjcm 7y ago
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 support. Compression wise AVIF is performing at about the same level as FLIF (15-25% better than webp, depending on the image), and is also royalty free. The leg it has upon FLIF is the Alliance for Open Media[1] is behind it, which is a consortium of companies including: "Amazon, Apple, ARM, Cisco, Facebook, Google, IBM, Intel Corporation, Microsoft, Mozilla, Netflix, Nvidia, Samsung Electronics and Tencent." I'm really excited for it and I hope it actually gets traction. It'd be lovely to have photos / screenshots / gifs all able to share a common format. [1] https://en.wikipedia.org/wiki/Alliance_for_Open_Media https://en.wikipedia.org/wiki/Alliance_for_Open_Media
- BurningCycles 7y ago
  >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 XL format with a ~20% size decrease (courtesy of the PIK project). It's slated for standardisation within a couple of weeks, it will be very interesting to see large-scale comparisons of this codec against the likes of AVIF and HEIF.
  - mceachen 7y ago
    Interesting. Where have you seen that adoption will be swifter with JPEG XL instead of, say, AV1/AVIF? (Speaking as someone who's seen several open, licensing-unencumbered image/video/audio formats fail to get traction with a majority of browsers).
    - BurningCycles 7y ago
userbinator 7y ago
I wonder how it compares with simply LZMA'ing (i.e. 7zip) a BMP. In my experience that has always been significantly smaller than PNG (which is itself a low bar --- deflate/zlib is a simple LZ+Huffman variant which is nowhere near the top of general-purpose lossless compression algorithms.) Along the same lines, I suspect BMP+LZMA would likely be beaten by BMP+PPM or BMP+PAQ, the current extreme in general-purpose compression.
- PetahNZ 7y ago
  Do you have any examples of zipped bmp's compared to png. Seem strange if that was indeed better.
  - clarry 7y ago
    Well I just took a screenshot and tried it. BMP: 6MB. lzma-compressed bmp: 75K. PNG through optipng and pngcrush: 178k. Not very surprising imho. PNG was never a strong compression format to begin with.
  - Dylan16807 7y ago
    It shouldn't be that surprising. PNG has a maximum window size of 32KB. That means you could use a small set of identical tiles to make an image, and PNG would have to store a new copy every row, because the previous row is out of range.
zelienople 7y ago
MacOS viewer does not work at all on any of the test images. Gives error "The document “5_webp_ll.flif” could not be opened."
0xff00ffee 7y ago
Isn't making it LGPL a problem? That means anything that touches it becomes LGPL, right?
- pgcj_poster 7y ago
  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.
  - mkl 7y ago
    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.
  - 0xff00ffee 7y ago
    > 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. Ah, thanks for the correction. I went through a legal headache years ago releasing some software and our lawyers strongly urged against *GPL and pushed us to Apache because we would have had severely limited our opportunity for Fortune 500 companies. Apparently many prohibit anything with the letters GPL in the license, despite that the software was free and we were charging for services. It was a long headspinning debate and due to mounting legal fees we went with Apache.
- dspillett 7y ago
  > That means anything that touches it becomes LGPL, right? Wrong, mostly. Any changes you make to the encoder library itself would be LGPL, but if all you are doing is calling the library from other code then that is not an issue. If you make a change to the library, even as part of a larger project, nothing else but that change is forced to be LGPL licensed. If your update is a bit of code you use elsewhere, as long as you own that code it does not force the elsewhere to be LGPL - while you are forced to LGPL the change to the library there is no stipulation that you can't dual license and use the same code under completely different terms outside the library.
octorian 7y ago
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.
- frandroid 7y ago
  In what way has PNG not already replaced TIFF?
  - labster 7y ago
    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.
  - emptybits 7y ago
    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.
- yread 7y ago
  TIFF is a versatile container format (like AVI) you can have tiffs with multiple images inside encoded with jpeg, jpeg xr, jp2k, LZW,... See https://en.m.wikipedia.org/wiki/TIFF#TIFF_Compression_Tag https://en.m.wikipedia.org/wiki/TIFF#TIFF_Compression_Tag
- jonsneyers 7y ago
  TIFF is a very hairy animal, but I'm happy to report that JPEG XL will be able to offer most of the functionality TIFF is currently used for: - multi-layer (overlays), with named layers - high bit depth - metadata (the JXL file format will support not just Exif/XMP but also JUMBF, which gives you all kinds of already-standardized metadata, e.g. for 360) - arbitrary extra channels All that with state-of-the-art compression, both lossy and lossless.
aidenn0 7y ago
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.
- chime 7y ago
  I think yes. From their site: https://flif.info/responsive.html 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.
pulse7 7y ago
It would be great to use this format for offline Wikipedia in Kiwix. This would substantially reduce its size...
canistel 7y ago
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?
- artificialidiot 7y ago
  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.
vardump 7y ago
> 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#tANS https://en.wikipedia.org/wiki/Asymmetric_numeral_systems#tAN...
- eln1 7y ago
  Jon Sneyers is currently working on JPEG XL, which uses ANS: https://www.spiedigitallibrary.org/conference-proceedings-of-spie/11137/2529237/JPEG-XL-next-generation-image-compression-architecture-and-coding-tools/10.1117/12.2529237.full?SSO=1 https://www.spiedigitallibrary.org/conference-proceedings-of...
- jonsneyers 7y ago
  Modular mode JPEG XL has MAANS (meta-adaptive ANS). It's indeed faster to decode than MANIAC, though a bit trickier to encode.
dusted 7y ago
We need this! :)
qwerty456127 7y ago
I have already converted all my JPEGs to WebP and configured my camera app to save directly to WebP. I hope one day I will be able to switch to FLIF the same way.
yason 7y ago
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 lossy photos and PNG for pixel-exact graphics. But most importantly they both compress substantially in comparison to uncompressed images (like TIFF) and both have long ago reached the level of compression where improving compression is mostly about diminishing gains. As there's less and less data left to compress further the compression ratio would need to go higher and higher for the new algorithm to make even a dent in JPEG or PNG in any practical sense. Also, image compression algorithms try to solve a problem that has been gradually made less and less important each year with faster network connections. Improvements in image compression efficiency are way outrun by improvements in the network bandwidth in the last 20 years. The available memory and disk space have grown enormously as well. For example, it's not so much of a problem if a background image of a website compresses down to 500Kb rather than 400Kb because the web page itself is 10M and always takes 10 seconds to load regardless of which decade it is. If you could squeeze a half-a-megabyte off the website's image data the site wouldn't effectively be any faster because of that (but maybe marginally so to allow the publisher to add another half-a-megabyte of ads or other useless crap instead.
- jillesvangurp 7y ago
  The reason we have jpeg is because png is not good enough for photos and people prefer the lossy compression of jpeg over using png. The reason other lossy formats are struggling is because they are still lossy. This promises to basically be good enough for just about anything. That sounds like a big promise but if true, there's very little stopping major browser implementing support for this. I'd say progressive decompression sounds like a nice feature to have for photo websites. Compression is still majorly important on mobile. Mobile coverage is mostly not great except maybe in bigger cities where you get to share the coverage with millions of others. Also mobile providers still throttle connections, bill per GB, etc. So, it matters. E.g. Instagram adopting this could be a big deal. All the major companies are looking to cut bandwidth cost. That's also what's driving progress for video codecs. With 4K and 8K screens becoming more common, jpeg is maybe not good enough anymore.
perenzo 7y ago
Introducing better compression of images and animations would be another small step fighting climate change. Less data, less transfer, less energy consumption! https://www.dw.com/en/is-netflix-bad-for-the-environment-how-streaming-video-contributes-to-climate-change/a-49556716 https://www.dw.com/en/is-netflix-bad-for-the-environment-how...
- flir 7y ago
  But more energy required to decompress, surely? (Not counting the compression step because I assume that's marginal at scale).
  - maximegarcia 7y ago
    Not necessarily, the decoding can be stopped once you get enough usable information in regards to the usage of the image (display size ...) with the same source image. That's neat! See the responsive part in https://flif.info/example.html https://flif.info/example.html We can imagine decoding taking into account battery save mode, bandwidth save mode...
nemo136 7y ago
you could have done "free lossless image compression" to have Flic-(Flac)
londons_explore 7y ago
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?
martin-adams 7y ago
It sure looks impressive. I think it's important to remember that comparing it to a lossy format will show it's disadvantages. For example on this demo: https://uprootlabs.github.io/poly-flif/ https://uprootlabs.github.io/poly-flif/ If you compare with "same size JPG" and set the truncation to 80%, JPG appears to win out in terms of clarity of the image.
jodrellblank 7y ago
If only it could focus the progressive download on areas of the picture, so it details faces in the early part of the file, and background in the later part.
- jonsneyers 7y ago
  JPEG XL will support exactly that! We call it saliency-based progressiveness.
ChrisLomont 7y ago
Jon Sneyers, the creator of FLIF speaking about Jpeg XL https://www.youtube.com/watch?v=lqi5U6dxeZU https://www.youtube.com/watch?v=lqi5U6dxeZU
TheRealPomax 7y ago
Pretty cool, but where are the links to the issues on mozilla, chromium, webkit, and edge's bug trackers to add native support for it? As an unencumbered open source technology, it should breeze through legal's OK pretty quickly, and getting it integrated could certainly take a bit of time, but should just be part of the FLIF roadmap itself, if the idea is to actually get this adopted. You don't set out to come up with "one format to rule them all" and then not also go "by implementing libflif and sending patches upstream to all the open source browsers that we want to see it used in" =)
jonsneyers 7y ago
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!

691 points by scotteh 7y ago

Checklist for how far it should go to be accepted format, applicable to JPEG XL too: - SIMD-optimised encoder/decoder for major programming languages; - stable photoshop and gimp import/export plugins, supporting layers, animation and transparency features; - metadata reading/writing library for major programming languages; - firefox and chrome integration at least.

SethTro 7y ago

The progressive loading video is great!

Polylactic_acid 7y ago
This is something I wish was used on the web. Imagine instead of creating a high compression image for use on a web page and then having a link for the full res one, you could just say "Load this image at 60%" and if users right click and save it would download the entire image.

Camas 7y ago

https://web.archive.org/web/20200207000006/https://flif.info/ https://web.archive.org/web/20200207000006/https://flif.info...

RcouF1uZ4gsC 7y ago

Seems really cool. It seems that the biggest gatekeepers for image formats are Apple and Google because of iPhone/Safari and Android/Chrome. Basically, if you want to be able to easily view the image on a mobile device or on the web, the format needs their blessing.

taneq 7y ago
They have a demo using a prototype browser polyfill so you could arguably use it right now at the cost of slightly higher CPU usage. Depending on your data connection it could even end up using less battery on mobile due to reduced radio usage.
gtirloni 7y ago
Well, Chromium is open source so it's open to anyone to implement it.
- nine_k 7y ago
  Is it easy to get your PR merged if it introduces support for a new image format?
- Polylactic_acid 7y ago
  Its about as useful as sending a politician an email. Technically the option exists but its not of much use.

ronyfadel 7y ago

Before Apple/Google/Mozilla adopt in their browsers, I doubt this will get any traction.

floatingatoll 7y ago
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 polyfill implementation is LGPLv3 as well, which may further harm adoption.
- deleted 7y ago
  [deleted]
- yellowapple 7y ago
  The decoder-only version of the reference implementation (libflif_dec) uses the Apache 2.0 license (specifically for this reason, I'd assume). Browsers shouldn't need to encode FLIF images very often, so decoder-only would be fine for that use case.
  - floatingatoll 7y ago
    Evaluating the efficacy of the new image codec is not possible using only a decoder. I was unable to find an APL2 JS polyfill decoder. Does one exist?
    - sjwright 7y ago
      How would the evaluation of any codec be hampered by any open source license?
      - Polylactic_acid 7y ago

Latty 7y ago

The section "Works on any kind of image" is really misleading, as it mentions JPEG as a lossy format (alongside JPEG 2000) then says "FLIF beats anything else in all categories." It really needs a giant caveat saying "lossless". I mean, that's still great and impressive, but it clearly doesn't erase the need for a user to switch formats as a lossless format is still not suitable for end users a lot of the time. (It does have a lossy mode, detailed on another page, but they clearly show it doesn't have the same advantage over other formats there.)

azinman2 7y ago
It literally stands for "FLIF - Free Lossless Image Format", and the first sentence is "FLIF is a novel lossless image format which outperforms PNG, lossless WebP, lossless BPG, lossless JPEG2000, and lossless JPEG XR in terms of compression ratio." Seems like they're doing a pretty decent job at communication it's lossless to me.
- kragen 7y ago
  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 image format to do that for images that have a lot of redundancy in a form that JPEG isn't sophisticated enough to recognize.)
  - lisper 7y ago
    > 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 outputs.

Camillo 7y ago

Looks great. What about decoding and encoding speed?

MonadIsPronad 7y ago
The TODO list mentions optimization, so probably not on par with the status quo yet, I'd guess.

foolrush 7y ago

Little mention of alpha encoding, something PNG absolutely botched. Unsurprising.

mark-r 7y ago
I've never noticed a problem with alpha in PNG, how did they botch it?

parvenu74 7y ago

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.

CobrastanJorji 7y ago
They could conceivably buy a different license from the author, if the author were to be interested in that, and if the author's the only contributor and didn't derive their code from othe LGPL code, etc, etc.
MonadIsPronad 7y ago
There's also an Apache 2 licenced decoder mentioned, perhaps with exactly this in mind...
- not2b 7y ago
  Only the encoder is LGPL, the decoder is Apache, web browsers only need a decoder.
nine_k 7y ago
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.
- DagAgren 7y ago
  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.
  - theon144 7y ago
    Uh, LGPL explicitly doesn't prevent even proprietary software from using the encoder?

tangm 7y ago

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 https://github.com/cloudinary/fuif [1] https://jpeg.org/jpegxl/index.html https://jpeg.org/jpegxl/index.html

pnako 7y ago
JPEG XL is either lossy compression for large pictures, or something named by people who suck at branding.
- deleted 7y ago
  [deleted]
- andrewzah 7y ago
  Made by the same folks who brought you JPEG 2000. /s
  - pmarreck 7y ago
    I was a fan/proponent of that! Whatever happened to wavelet compression?
    - loeg 7y ago
      Patents.
      - ksec 7y ago
        Most of them had expired. Wavelet is something that looks good in theory but in practice couldn't beat the millions man hours work put into standard DCT.
- Double_a_92 7y ago
  And AVIF was that weird video format before mp4 became common everywere, right? /s

MonadIsPronad 7y ago

Very cool, hoping to see more of this in the future. Good job team

pier25 7y ago

They have a polyfill for browsers: https://github.com/UprootLabs/poly-flif 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.

hug 7y ago
While weight is a factor in professional car racing, and while I've built a go-kart that is significantly lighter in weight than a professional racing car, it is not a particularly impressive achievement that I have managed to do so, and I wouldn't think to criticize a race team for the weight of their vehicle.
- andrewzah 7y ago
  Good thing we’re discussing JavaScript library sizes and not cars in random contexts, then. 77kb gzipped is massive considering it’s only doing one thing. If I want my website to load in ~100 milliseconds or less (or even 1 second or less!), I absolutely do need to pay attention to all the libraries I add. I can and do criticize software developers for making hideously bloated websites because they don’t pay attention to what they add. Not only are a lot of modern websites wasteful, they’re painful or outright useless on slow mobile connections—not a problem for software developers on fibre networks, beefy dev machines, etc.
  - hug 7y ago
    So it turns out that the use-case for a polyfill of a 77KB image decoder isn't particular suited to a site you want to load in sub 100ms. Oddly, though, that's not the only usecase in the world, and there are circumstances where saving ~30% on every image load turns out to be significantly more efficient than not loading a 77KB JS library. In other news, I also chose to forgo adding a 15 lb. fuel pump to my go-kart, despite the fact that every NASCAR team in the world uses one, and my go-kart drives just fine. I should go tell the NASCAR teams that fuel pumps are a terrible idea. I clearly know something they don't.

dang 7y ago

Related from 2016: https://news.ycombinator.com/item?id=12626451 https://news.ycombinator.com/item?id=12626451 https://news.ycombinator.com/item?id=11238190 https://news.ycombinator.com/item?id=11238190 2015: https://news.ycombinator.com/item?id=10317790 https://news.ycombinator.com/item?id=10317790

The_rationalist 7y ago

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

sjwright 7y ago
No codec is “ubiquitous” until it is.
re 7y ago
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 https://en.wikipedia.org/wiki/JPEG_XR
- The_rationalist 7y ago
  Correct.

mindslight 7y ago

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 FLAC for my music collection ~15 years ago, and that working out fantastically. If a better format does come along, or if I change my mind, I can always transcode.

colejohnson66 7y ago
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?
- catalogia 7y ago
  > Also, why not PNG? The article claims 43% improvement over typical PNGs, if you have a lot of images that's pretty significant.
- mindslight 7y ago
  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.

sd314 7y ago

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

nine_k 7y ago
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.
- sd314 7y ago
  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.
  - adev_ 7y ago
    > Best practices and rules in C++ are changing on a daily basis as the language is still evolving. Yeah "daily", C++ standard evolves every 3 years minimum and most API are still C++11 meaning 9 years old. "Daily" right ? This is FUD. Without even mentioning that any C++lib can expose a C API.

bawolff 7y ago

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.

kccqzy 7y ago
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.
- yjftsjthsd-h 7y ago
  That's part of the benefit of zstd, as I understand it; near-xz compression ratios but much faster.
  - loeg 7y ago
    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.
    - yjftsjthsd-h 7y ago
      Yeah, that's a useful distinction. So it's excellent for ex. packages (hence https://www.archlinux.org/news/now-using-zstandard-instead-of-xz-for-package-compression/ 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)
      - loeg 7y ago
        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.)

sand500 7y ago

In terms of getting it into chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=539120 https://bugs.chromium.org/p/chromium/issues/detail?id=539120 > Keep in mind that the author of the FLIF works on the new FUIF (https://github.com/cloudinary/fuif https://github.com/cloudinary/fuif) which will be part of the JPEG XL. So, probably FLIF will be deprecated soon. And as far as JPEG XL is also based on Google PIX, there is a high probability that Google will support this new format in their Blink engine. https://jpeg.org/jpegxl/index.html https://jpeg.org/jpegxl/index.html

markdog12 7y ago
You can encode to JPEG XL here: https://libwebpjs.appspot.com/jpegxl/ https://libwebpjs.appspot.com/jpegxl/ (Compiled to WebAssembly, not by me)
jiofih 7y ago
Is JPEG XL also suited to replace PNG like FLIF?
- andrius4669 7y ago
  yeah. it's partially based on https://github.com/cloudinary/fuif https://github.com/cloudinary/fuif so if you use that part of JPEG XL you'll get something similar out of it.
  - janwas 7y ago
    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.
    - JyrkiAlakuijala 7y ago
      Also other famous compression gurus, including Alex Rhatushnyak and Lode Vandevenne contributed to the lossless side of JPEG XL.

jjcm 7y ago

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 support. Compression wise AVIF is performing at about the same level as FLIF (15-25% better than webp, depending on the image), and is also royalty free. The leg it has upon FLIF is the Alliance for Open Media[1] is behind it, which is a consortium of companies including: "Amazon, Apple, ARM, Cisco, Facebook, Google, IBM, Intel Corporation, Microsoft, Mozilla, Netflix, Nvidia, Samsung Electronics and Tencent." I'm really excited for it and I hope it actually gets traction. It'd be lovely to have photos / screenshots / gifs all able to share a common format. [1] https://en.wikipedia.org/wiki/Alliance_for_Open_Media https://en.wikipedia.org/wiki/Alliance_for_Open_Media

BurningCycles 7y ago
>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 XL format with a ~20% size decrease (courtesy of the PIK project). It's slated for standardisation within a couple of weeks, it will be very interesting to see large-scale comparisons of this codec against the likes of AVIF and HEIF.
- mceachen 7y ago
  Interesting. Where have you seen that adoption will be swifter with JPEG XL instead of, say, AV1/AVIF? (Speaking as someone who's seen several open, licensing-unencumbered image/video/audio formats fail to get traction with a majority of browsers).
  - BurningCycles 7y ago

userbinator 7y ago

I wonder how it compares with simply LZMA'ing (i.e. 7zip) a BMP. In my experience that has always been significantly smaller than PNG (which is itself a low bar --- deflate/zlib is a simple LZ+Huffman variant which is nowhere near the top of general-purpose lossless compression algorithms.) Along the same lines, I suspect BMP+LZMA would likely be beaten by BMP+PPM or BMP+PAQ, the current extreme in general-purpose compression.

PetahNZ 7y ago
Do you have any examples of zipped bmp's compared to png. Seem strange if that was indeed better.
- clarry 7y ago
  Well I just took a screenshot and tried it. BMP: 6MB. lzma-compressed bmp: 75K. PNG through optipng and pngcrush: 178k. Not very surprising imho. PNG was never a strong compression format to begin with.
- Dylan16807 7y ago
  It shouldn't be that surprising. PNG has a maximum window size of 32KB. That means you could use a small set of identical tiles to make an image, and PNG would have to store a new copy every row, because the previous row is out of range.

zelienople 7y ago

MacOS viewer does not work at all on any of the test images. Gives error "The document “5_webp_ll.flif” could not be opened."

0xff00ffee 7y ago

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

pgcj_poster 7y ago
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.
- mkl 7y ago
  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.
- 0xff00ffee 7y ago
  > 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. Ah, thanks for the correction. I went through a legal headache years ago releasing some software and our lawyers strongly urged against *GPL and pushed us to Apache because we would have had severely limited our opportunity for Fortune 500 companies. Apparently many prohibit anything with the letters GPL in the license, despite that the software was free and we were charging for services. It was a long headspinning debate and due to mounting legal fees we went with Apache.
dspillett 7y ago
> That means anything that touches it becomes LGPL, right? Wrong, mostly. Any changes you make to the encoder library itself would be LGPL, but if all you are doing is calling the library from other code then that is not an issue. If you make a change to the library, even as part of a larger project, nothing else but that change is forced to be LGPL licensed. If your update is a bit of code you use elsewhere, as long as you own that code it does not force the elsewhere to be LGPL - while you are forced to LGPL the change to the library there is no stipulation that you can't dual license and use the same code under completely different terms outside the library.

octorian 7y ago

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.

frandroid 7y ago
In what way has PNG not already replaced TIFF?
- labster 7y ago
  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.
- emptybits 7y ago
  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.
yread 7y ago
TIFF is a versatile container format (like AVI) you can have tiffs with multiple images inside encoded with jpeg, jpeg xr, jp2k, LZW,... See https://en.m.wikipedia.org/wiki/TIFF#TIFF_Compression_Tag https://en.m.wikipedia.org/wiki/TIFF#TIFF_Compression_Tag
jonsneyers 7y ago
TIFF is a very hairy animal, but I'm happy to report that JPEG XL will be able to offer most of the functionality TIFF is currently used for: - multi-layer (overlays), with named layers - high bit depth - metadata (the JXL file format will support not just Exif/XMP but also JUMBF, which gives you all kinds of already-standardized metadata, e.g. for 360) - arbitrary extra channels All that with state-of-the-art compression, both lossy and lossless.

aidenn0 7y ago

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.

chime 7y ago
I think yes. From their site: https://flif.info/responsive.html 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.

pulse7 7y ago

It would be great to use this format for offline Wikipedia in Kiwix. This would substantially reduce its size...

canistel 7y ago

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?

artificialidiot 7y ago
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.

vardump 7y ago

> 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#tANS https://en.wikipedia.org/wiki/Asymmetric_numeral_systems#tAN...

eln1 7y ago
Jon Sneyers is currently working on JPEG XL, which uses ANS: https://www.spiedigitallibrary.org/conference-proceedings-of-spie/11137/2529237/JPEG-XL-next-generation-image-compression-architecture-and-coding-tools/10.1117/12.2529237.full?SSO=1 https://www.spiedigitallibrary.org/conference-proceedings-of...
jonsneyers 7y ago
Modular mode JPEG XL has MAANS (meta-adaptive ANS). It's indeed faster to decode than MANIAC, though a bit trickier to encode.

dusted 7y ago

We need this! :)

qwerty456127 7y ago

I have already converted all my JPEGs to WebP and configured my camera app to save directly to WebP. I hope one day I will be able to switch to FLIF the same way.

yason 7y ago

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 lossy photos and PNG for pixel-exact graphics. But most importantly they both compress substantially in comparison to uncompressed images (like TIFF) and both have long ago reached the level of compression where improving compression is mostly about diminishing gains. As there's less and less data left to compress further the compression ratio would need to go higher and higher for the new algorithm to make even a dent in JPEG or PNG in any practical sense. Also, image compression algorithms try to solve a problem that has been gradually made less and less important each year with faster network connections. Improvements in image compression efficiency are way outrun by improvements in the network bandwidth in the last 20 years. The available memory and disk space have grown enormously as well. For example, it's not so much of a problem if a background image of a website compresses down to 500Kb rather than 400Kb because the web page itself is 10M and always takes 10 seconds to load regardless of which decade it is. If you could squeeze a half-a-megabyte off the website's image data the site wouldn't effectively be any faster because of that (but maybe marginally so to allow the publisher to add another half-a-megabyte of ads or other useless crap instead.

jillesvangurp 7y ago
The reason we have jpeg is because png is not good enough for photos and people prefer the lossy compression of jpeg over using png. The reason other lossy formats are struggling is because they are still lossy. This promises to basically be good enough for just about anything. That sounds like a big promise but if true, there's very little stopping major browser implementing support for this. I'd say progressive decompression sounds like a nice feature to have for photo websites. Compression is still majorly important on mobile. Mobile coverage is mostly not great except maybe in bigger cities where you get to share the coverage with millions of others. Also mobile providers still throttle connections, bill per GB, etc. So, it matters. E.g. Instagram adopting this could be a big deal. All the major companies are looking to cut bandwidth cost. That's also what's driving progress for video codecs. With 4K and 8K screens becoming more common, jpeg is maybe not good enough anymore.

perenzo 7y ago

Introducing better compression of images and animations would be another small step fighting climate change. Less data, less transfer, less energy consumption! https://www.dw.com/en/is-netflix-bad-for-the-environment-how-streaming-video-contributes-to-climate-change/a-49556716 https://www.dw.com/en/is-netflix-bad-for-the-environment-how...

flir 7y ago
But more energy required to decompress, surely? (Not counting the compression step because I assume that's marginal at scale).
- maximegarcia 7y ago
  Not necessarily, the decoding can be stopped once you get enough usable information in regards to the usage of the image (display size ...) with the same source image. That's neat! See the responsive part in https://flif.info/example.html https://flif.info/example.html We can imagine decoding taking into account battery save mode, bandwidth save mode...

nemo136 7y ago

you could have done "free lossless image compression" to have Flic-(Flac)

londons_explore 7y ago

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?

martin-adams 7y ago

It sure looks impressive. I think it's important to remember that comparing it to a lossy format will show it's disadvantages. For example on this demo: https://uprootlabs.github.io/poly-flif/ https://uprootlabs.github.io/poly-flif/ If you compare with "same size JPG" and set the truncation to 80%, JPG appears to win out in terms of clarity of the image.

jodrellblank 7y ago

If only it could focus the progressive download on areas of the picture, so it details faces in the early part of the file, and background in the later part.

jonsneyers 7y ago
JPEG XL will support exactly that! We call it saliency-based progressiveness.

ChrisLomont 7y ago

Jon Sneyers, the creator of FLIF speaking about Jpeg XL https://www.youtube.com/watch?v=lqi5U6dxeZU https://www.youtube.com/watch?v=lqi5U6dxeZU

TheRealPomax 7y ago

Pretty cool, but where are the links to the issues on mozilla, chromium, webkit, and edge's bug trackers to add native support for it? As an unencumbered open source technology, it should breeze through legal's OK pretty quickly, and getting it integrated could certainly take a bit of time, but should just be part of the FLIF roadmap itself, if the idea is to actually get this adopted. You don't set out to come up with "one format to rule them all" and then not also go "by implementing libflif and sending patches upstream to all the open source browsers that we want to see it used in" =)

jonsneyers 7y ago

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!