101–110 of 121 posts
Earlier quoted context omitted.
Looks like FLIF can do animations as well. http://flif.info/animation.html
FLIF is encumbered by GPL which means it's not going to make it into any digital cameras.
How does this compare to FLIF? The responsive features of FLIF seem fantastic. http://flif.info/
FLIF is based on context mixing so it's extremely slow but has an extremely high (lossless) compression ratio. It's designed for image archival and not for real-time streaming video. It does have some interlacing techniques for previewing the image in a lower resolution but really it's orders of magnitude slower than other image formats.
Earlier quoted context omitted.
In the part where it says "Spot the difference" and everyone says "The BPG one looks worse". That's because BPG, even in "lossless" mode... is lossy. So you're taking a video with H.264 compression artifacts and recompressing it with HEVC artifacts. The quality can only go down. FLIF on the other hand is lossless, so the image would be truly identical (pixel for pixel). However the filesize will likely be much larger…
FLIF is encumbered by GPL, so it is unlikely to make its way into digital cameras.
Earlier quoted context omitted.
In the part where it says "Spot the difference" and everyone says "The BPG one looks worse". That's because BPG, even in "lossless" mode... is lossy. So you're taking a video with H.264 compression artifacts and recompressing it with HEVC artifacts. The quality can only go down. FLIF on the other hand is lossless, so the image would be truly identical (pixel for pixel). However the filesize will likely be much larger…
FLIF is encumbered by GPL, so it is unlikely to make its way into digital cameras.
2) The reference implementation will most likely change to a more permissive license, cf https://github.com/FLIF-hub/FLIF/issues/192
3) If digital cameras would use FLIF, they would probably need to implement a simplified encoder in hardware, e.g. one that uses a hardcoded (set of) MANIAC tree(s) and only uses a subset of the available encoding options. Otherwise it will be too slow.
Earlier quoted context omitted.
FLIF only has a lossless mode. For lossless animation, it usually beats GIF, APNG, MNG, WebP and BPG. It is the only responsive animation format afaik. For lossy movies, actual video codecs are best, since they're designed for that. BPG is essentially HEVC (a great but patent-encumbered video codec) so it should be good at lossy movies -- it will be worse on line-art animations with hard edges like e.g. cartoons, or…
I don't think this is entirely fair. The full encoding of FLIF is lossless, yes, but it has VERY strong progressive decoding. You could just truncate the file at x% and get lossy encoding that way.
However, truncated FLIF files will (probably) never achieve the same quality/size ratio as dedicated lossy methods that can produce a completely different file for each quality setting.
So at the moment I still see an important use case for lossy methods. However, in the future, I can imagine that people will start to demand/expect lossless encoding, to avoid generation loss and to get the most out of their display hardware. E.g. higher bit depths are becoming a thing, while the JPEG/WebP color space (YCbCr) is effectively less than 22 bits per pixel (roughly speaking, red and blue are only 7-bit), and chroma subsampling makes this even worse. Also what's the use of ever higher display resolutions if most of those pixels are only displaying compression artifacts or blur? Lossy formats like JPEG/WebP/BPG/JP2/JXR are good at medium-quality, but if you use them at a near-lossless quality setting (e.g. 99 or 100 for JPEG), they often produce bigger files than lossless formats.
Meanwhile, the range of display sizes is getting larger: while in the past, we had a range from say 13" monitors to 21" monitors, now we have a range from 1.5" smart watches to huge 100" smart TVs. I do think that in order to avoid huge amounts of rescaling/transcoding, we need image/video formats that are "responsive by design", like JPEG2000 and FLIF (and progressive JPEG to some extent).
Why can't we just use MP4? Add an inline JavaScript decoder for Mobile Safari, and then at least all the other browsers get instant hardware decoding. Are there trust issues with allowing third-party MP4 embeds into user-submitted content such as forums/hosted blogs? Do we need a "no sound"/"max file size" attribute on the video tag?
Earlier quoted context omitted.
FLIF is encumbered by GPL which means it's not going to make it into any digital cameras.
The first official version of FLIF has not been released yet, and currently they are discussing releasing it under Apache 2 or MPL (Mozilla Public License).
And I dont know of any popular project that uses MPL apart from Mozilla Firefox.
HEVC Advance now changes an additional 50M/year to the 25M/year with MPEG-LA.
Earlier quoted context omitted.
I don't think this is entirely fair. The full encoding of FLIF is lossless, yes, but it has VERY strong progressive decoding. You could just truncate the file at x% and get lossy encoding that way.
Thanks for the compliment about FLIF's progressive decoding! (FLIF author speaking here) However, truncated FLIF files will (probably) never achieve the same quality/size ratio as dedicated lossy methods that can produce a completely different file for each quality setting. So at the moment I still see an important use case for lossy methods. However, in the future, I can imagine that people will start to demand/expe…