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.
FLIF – Free Lossless Image Format
41–50 of 254 posts
Re: FLIF – Free Lossless Image Format
#42In terms of getting it into chrome:
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) 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.
Re: FLIF – Free Lossless Image Format
#43I 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.
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.
Re: FLIF – Free Lossless Image Format
#44In terms of getting it into chrome: 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 ) 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…
You can encode to JPEG XL here: https://libwebpjs.appspot.com/jpegxl/
(Compiled to WebAssembly, not by me)
Re: FLIF – Free Lossless Image Format
#45Earlier quoted context omitted.
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.
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 attentio…
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.
Re: FLIF – Free Lossless Image Format
#46Seems 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.
Well, Chromium is open source so it's open to anyone to implement it.
Is it easy to get your PR merged if it introduces support for a new image format?
Re: FLIF – Free Lossless Image Format
#47Always 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.
Re: FLIF – Free Lossless Image Format
#48Before Apple/Google/Mozilla adopt in their browsers, I doubt this will get any traction.
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 poly…
It's FUD time!
The LGPL is hardly "restrictive". If you aren't modifying the code, and for a codec if you are I have questions, then you've nothing to worry about.
Regarding license compatibility, which actually existing browser are you worried about the licensing terms of?
Re: FLIF – Free Lossless Image Format
#49It 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
JXL is an interesting standard. Integrates a recompressor that shaves ~20% off .jpgs without further loss(!), FUIF for essentially-lossless images in a progressive/interlaced mode like this, a separate lossless format, and a new lossy format with variable-sized DCTs and a bunch of other new tools (other transforms for DCT-unfriendly content, postfilter for DCT artifacts, new colorspace, chroma-from-luma...). It's int…
I think the progressive loading feature of FLIF/FUIF/JXL would be really interesting for WebGL. WebGL games already have asynchronous resource loading and incremental image decoding/texture upload just by virtue of using the available APIs. One could get a pseudo texture streaming effect by default (although no unloading of textures...)
Re: FLIF – Free Lossless Image Format
#50Earlier quoted context omitted.
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.
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 outputs.