Hacker News Reader

Comment by klodolph | Hacker News Reader

The problem with FLIF here is that it's not remotely competitive when you're using a lossy format for both the low-quality and high-quality versions, which is the most common case for photos. UI elements tend to be small, so it doesn't matter.

In most cases if you get more bandwidth which you could spend on using a lossless FLIF, you would get better subjective quality by using a higher resolution JPEG at the same file size.

View on HN

If you need to use an image twice, once low-quality and once high-quality but not perfect, FLIF would let you load (say) 10% of the image in one place and 50% in another.

Are you saying that for the same bandwidth usage, you could load two separate lossy JPGs and they'd look better?

What if the fact that you've loaded the first 10% of the FLIF for the low-res version means you can resuse that data and start with the 11th percent when loading the high-res version?

> Are you saying that for the same bandwidth usage, you could load two separate lossy JPGs and they'd look better?

The tests I've done are along the lines of this (I forget the exact numbers I used):

* JPEG: 10kB + 90kB

* FLIF: 100kB

JPEG usually wins for photographic source material. I was unable to come up with “reasonable” parameters where FLIF would win, but perhaps someone creative can figure that part out.

You didn't mention the result of your tests, but I infer that you found the 90 kB JPEG to be superior to the 100 kB FLIF/PNG? That seems reasonable, if unfortunate.

Yes, for photographs. This shouldn't be surprising.

Note that the FLIF home page doesn't even claim that FLIF is superior to normal JPEG images... it only claims that it's superior to other lossless formats. For lossless formats, you can compare your desired metric (e.g. file size) for your corpus. For lossy formats, you can either fix subjective quality and compare size, or fix size and compare subjective quality. (Or compare some other metric, but these two are more common.)

These are completely different ways of evaluating compression algorithms, and it intuitively makes sense that different algorithms will be better if you evaluate them differently.

Consider that FLAC gives the best bitrate for lossless audio, but Opus gives a far better bitrate when you fix the subjective quality or a better quality when you fix the bitrate at reasonable rates.

Or consider that there is a wide spectrum of data compression algorithms, each of which performs the best depending on how you assign weight to compression speed, decompression speed, and compression ratio, and what is in your corpus. There is a surprising variety of new compression algorithms out there, some of which may be the best for your use case even though their compression ratios are significantly worse than other well-known algorithms (LZ4, LZFSE, Snappy, for example).

JPEG is designed for best quality at reduced bit rates, so it should not be surprising that it is good at doing that, even though it is old and newer algorithms are better.

Which is why we need a replacement for Jpeg. While bpg / HEVC is a lot better, sometimes i wonder if we can do more. While I can shrink a 100kb Jpeg to 50Kb Bpg and looks better, what I really want is something 100Kb Jpeg quality at 30Kb or less.

But given bpg or HELF isn't even being used yet. I know i am asking for a lot.

You mean HEIF?

It took 22 years to get from JPEG to BPG, it will probably be a while before we get something noticeably better :-)

I didn't even know about BGP! BGP looks great.

Today I also learned that HEVC is another name for x265.

Congratulations, you've reinvented the progressive jpeg.

Reply on news.ycombinator.com