5 ms·
I don't feel like that page is entirely fair. The PNG and GIF comparisons are unfair; they're the same low resolution as FLIF, but given nearest-neighbor upsam
by silverbacknet 11y ago
I don't feel like that page is entirely fair.
The PNG and GIF comparisons are unfair; they're the same low resolution as FLIF, but given nearest-neighbor upsampling instead of bilinear. Most web browsers use bilinear or bicubic upsampling for progressive pictures now, so FLIF isn't nearly as unique as it presents itself. Aside from that, progressive is only useful if you're on a slow connection or the file is broken; in other cases re-rendering multiple times becomes a bottleneck and battery drain. In general it's rare that progressive decoding is a win anymore (although progressive encoding of JPEG is always a win).
In another comment I pointed out that jpeg2000 can be encoded to any size, even 1k, even though the q-scale doesn't go that low, by using the target size parameter instead. It looks better than anything but BPG and is fully progressive. Of course, J2K is a dead format outside of DejaVu, PDF, and the medical field, but it serves as a useful baseline.
A comparison to JXR would have been nice; it's an open, patent-indemnified format that fully supports progressive decoding, and compresses about as well as WebP. That format's the biggest disappointment for me, I thought it had everything in place to displace JPEG.
BPG could be made somewhat progressive, but only by changing the underlying HEVC bitstream, while one of its goals is to stay as close as possible. The inclusion of a thumbnail is the only recourse.
- jonsneyers 11y agoYou're right about the interpolation method (bilinear vs nearest-neighbor), it's indeed not a fair comparison in that respect. However, I do think that most PNG viewers use nearest-neighbor (at least that's what my viewer did when I gave it a partial PNG file). But it's not just the interpolation that makes a difference: PNG interlaces full RGB pixels (all 3 channels at the same time), while FLIF gives priority to luma so you get a chroma subsampling effect on partial files. Also GIF only has vertical interlacing and PNG only does 7 passes of 2D interlacing, which means that for huge images, the first pass can still take a while. Another point: I am proposing to use progressive decoding to avoid having to download the full lossless image (so a browser supporting FLIF would need some mechanism to stop downloading the image file when "enough" detail is available). Repeated re-rendering is not necessary. E.g. on a mobile phone you would rather just download some prefix of the file (the size of the prefix could depend on the available bandwidth) and render it once, at least until the user zooms in on the image, or saves or prints it or something -- then the download should be resumed in order to load more/all detail.