I experimented with this a while back as a possible lossless carrier for remote desktop- style applications for window contents that had lossless,interactive as requirements.
Some really nice choices in this one, including YCoCg as colorspace and the ability of being able to progressively render the contents on slow network links - which meant the user could get enough visibility to make input decisions and cancel the ongoing image transfer in favour of the next one on input.
The downsides at the time, as with bootstrapping any new image compression really, is that it was too slow to be practical over accepting lossy on back pressure, ramping up the bitrate and go with h264 I-frames from hardware encoder.
The home page is clear on how smaller the files are but I’d like to see more about the costs (cpu, memory, code size) of encoding and decoding. Is there an article about that ? Does someone here have some answers ?
Sounds pretty nice, but how well is this format supported?
About not at all. No browser and no major tool apart ImageMagick.
“Works on any kind of image” is really misleading, as it mentions JPEG along JPEG 2000 as a lossy format but 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.)
JPEG XL (what a name) builds upon the ideas found in FLIF (and FUIF and PIK, IIRC.) Maybe that one has a chance of catching on, and bringing those ideas to the mainstream.
I was sceptical (yeah, the name), but it looks like that’s exactly the case, reading the comment here:
Edit: Just saw the other story about JPEG XL on the front page.