21–30 of 53 posts
But given what we have already seen from Nvidia on video compression [0], I think within the next few years, we will move everything to machine-learning-'compressed' images (aka transmitting a super-low-res seed image and some additional ASCII and having an ML model reconstruct and upscale it at the client side).
[0] https://www.dpreview.com/news/5756257699/nvidia-research-dev...
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.
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.
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 jpegjxl 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)
I love this and would have dearly needed it like 5 years ago. Now, it is still a very interesting read. But given what we have already seen from Nvidia on video compression [0], I think within the next few years, we will move everything to machine-learning-'compressed' images (aka transmitting a super-low-res seed image and some additional ASCII and having an ML model reconstruct and upscale it at the client side). […
Thing I'd love to try if I had time - a compressor which derives the best table for the image. I'm imagining a loop of: start with the default, compress, calculate the difference from the original, dct the error to see which patterns are missed, adjust the table, repeat. Stop on some given error/size-increase ratio. (yes, I'm trying to get someone else nerd sniped into doing this) Edit: something like this https://ww…
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.
Does this mean default quantization tables were badly picked after all? And someone only noticed after 30 years? It sounds like the employed solution only modifies first element from [16,17] to [10,16].
It is no secret that high resolution images and low resolution images compress differently, and modern codecs are optimized for high resolutions in a way that older codecs weren't. For example going from H.261 to H.266 globally improve video compression at every step, but it is most apparent at higher resolutions.
How is this different from say, what https://kraken.io is doing. When I upload images there I get a smaller file size and the image looks no different
How is this different from say, what https://kraken.io is doing. When I upload images there I get a smaller file size and the image looks no different
In other words: end users use kraken, developers read this article.
Does this mean default quantization tables were badly picked after all? And someone only noticed after 30 years? It sounds like the employed solution only modifies first element from [16,17] to [10,16].
The tables were good for the time they were picked. And the beginning of the article, it shows that at low resolutions, both ringing and banding are unacceptable. At high resolutions, beyond what was considered normal when the original quantization tables were chosen, then ringing becomes much less of a problem, so it makes sense now to change the quantization tables to prioritize banding over ringing. It is no secre…
Slightly more precise: ringing becomes much less of a problem in high resolution images when viewed on a high resolution screen (in Apple language: retina).