11–20 of 45 posts
I'd be curious to see what the result would be if you took the best format for each individual image and added them together; would it be a significant difference over FLIF by itself? The choice of GPLv3 licensing is unfortunate, since it will limit native browser support.
I assume the news is this recent conference paper: http://flif.info/papers/FLIF_ICIP16.pdf
It will be great when you only need one file for all of your responsive image versions and can just take the part you need. Plug - I wrote about this in my high performance web app book along with other types of compression (https://www.packtpub.com/mapt/book/Application%20Development...).
Apparently the WIP warning was also removed from the site lately[1]. Can we infer that the format is being finalized? [1] https://github.com/FLIF-hub/FLIF-hub.github.io/commit/2b9c81...
You'd want to maximize adoption, and there BSD can help. Adoption of Xiph.org's Vorbis was in good part supported by such a decision.
I'd be curious to see what the result would be if you took the best format for each individual image and added them together; would it be a significant difference over FLIF by itself? The choice of GPLv3 licensing is unfortunate, since it will limit native browser support.
That's the encoder , which isn't something browsers would usually bother with. The decoder is Apache licensed.
When trying to promote an open format, LGPLv3 and such reference implementations aren't exactly helping. You'd want to maximize adoption, and there BSD can help. Adoption of Xiph.org's Vorbis was in good part supported by such a decision.
The thing about flif that feels good on the old noggin is the fact that you can trade off quality for size just by truncating the file. Imagine a decimal point at the beginning of the file, and your image is a number between 0 and 1. Approximate that number to N digits, and you get an approximation of your image.