Hacker News new | ask | show | jobs
by cabirum 1461 days ago
There's also webp and heif and png and svg, and I believe all the existing formats already solve the image compression problem. The difference of 18kb vs 22kb from hours of microoptimisations is frankly irrelevant given the rate of networks getting faster.
3 comments

Don't tell that to NFT people who want to put everything on-chain but have to sell their house in gas fees to store a small jpg on Ethereum! It's like the 70s all over again, but with blockchain instead of floppy disks. (I've seen a few of them discuss better compression algorithms because they really felt it was extremely useful and meaningful to store the actual data on-chain and not a IPFS link like they usually do)
The simple question: if all the existing formats already solve the image compression problem, why a new image formats (WebP, HEIC, AVIF, JPEG XL etc) appears?
As computers generally get faster, more expensive encoding can be considered.

I'm using different tooling on an AMD 3900x for these conversions, so take these numbers with a grain of salt.

    $ gm identify test.tiff
    test.tiff TIFF 6240x4160+0+0 DirectClass 8-bit 1.2Mi 0.000u 0m:0.000001s

    $ time gm convert test.tiff test.jpg

    real 0m0.282s
    user 0m0.193s
    sys 0m0.089s

    $ time heif-enc test.jpg -o test.heif

    real 0m1.901s
    user 0m22.960s
    sys 0m0.180s

So... that's literally 100x more CPU time to encode the HEIF than the JPEG. The JPEG is 1.1M, and the HEIF is 800K.

In my prior tests AV1 is 2-5x slower than HEIF, and JPEG-XL is ~10x slower.

Not even that but the chosen reference of the same file size (Q15+Fix vs QL18) is hardly distinguishable to me.

In essence, the author discovered how to make JPEG images look better by increasing their file size.

>Q15+Fix vs QL18) is hardly distinguishable to me.

What can I say, it is very distinguishable to me, at least for images that contain larger "homogeneous" areas like skies.

>In essence, the author discovered how to make JPEG images look better by increasing their file size.

This is not what the article is about. E.g. the first image with the large blue sky area, the result was a file size that was halved for Q15+fix compared to the Q50 source, and the Q18 comparison image at the same file size as Q15+fix looks like crap.

So the author got vastly more visual quality for the same or similar file size, while still producing valid jpegs.

It might not matter that much in the grand scheme of things, but it probably matters a lot to the company he is working for, which specializes in image processing, compression and delivery as a service it seems (bandwidth and traffic are cheap, but not free). And it will probably matter at least for some of their customers as well.

It probably won't matter much if you are e.g. on reddit (or are reddit), and that post with that 90kb jpeg (which could have been maybe 50-60 kb with the optimizations mentioned in the article) pulled in 10.1 MB of other crap (wire size) in the 30 seconds the page was open. With an ad-blocker active. Yes, I just ran this very unscientific test.

In the future, other formats like webp (already somewhat widely deployed), avif (browser support is getting there) or jpeg-xl (very promising results per watt compared to avif and sometimes webp, with a nifty lossless jpeg<->jxl mode) - but probably not heif because of the patent situation - might become more dominant, but for the time being a lot of images online and offline will remain jpeg and produced as jpegs.

(png and svg the grandparent poster brought up are for other use cases, btw, and offer lousy to untenable compression for photographs)