[1] https://sprzedajemy.pl/www-magazyn-internetowy-2003-nr-04-03... - incidentally this must be the very issue, see the teaser about image optimization
Even for the past 20 years, when I read webpages with images, I inspect them closely. Often it’s something like a newspaper article with photographs or Wikipedia. I specifically set my Wikipedia settings to deliver me images at the highest possible resolution and now I can actually enjoy reading it. Specifically I use the Timeless skin and set the thumbnail size to the maximum.
Sometimes I come across webpages that describe something like historic trains and all they have are icon sized photographs of them. It’s so sad.
Edit: something like this https://www.imaging.org/site/PDFS/Papers/2003/PICS-0-287/849...
So from the older known ones there DCTune and DCTex methods, but it seems neither is available for download anywhere.
MozJPEG [1] includes several quantization tables that are optimized for different contexts (see the quant-table flag and source code for specific tables[2]), and the default quantization table has been optimized to outperform the recommended quantization tables in the original JPEG spec (Annex K).
It's also worth noting that MozJPEG uses Trellis quantization [3] to help improve quality without a per-image quantization table search. Basically rather than determining an optimal quantization table for the image, it minimizes rate distortion on a per-block level by tuning the quantized coefficients.
Both the SSIM and PSNR tuned quantization tables (2 and 4) provided by MozJPEG use a lower value in the first position of the quantization just like this article suggests (9 and 12 vs the libjpeg default of 16).
[1] https://github.com/mozilla/mozjpeg
[2] https://github.com/mozilla/mozjpeg/blob/5c6a0f0971edf1ed3cf3...
It has lower value in the first position of the base table, i.e. the table which is used for q=50. With lower qualities this value scales up. This delays color banding from q=50 to roughly say q=40, after that the same effect is appears.
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...
Better encoders for JPEG or PNG are the main avenues how you can achieve improvements without compatibility problems, and I think that will stay true for another decade, if not more.
lossy compression is one thing, but to just say that an ML model suggests making pixels like this vs a mathematical formula is totally different things.
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
In my prior tests AV1 is 2-5x slower than HEIF, and JPEG-XL is ~10x slower.
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 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)
You can re-save a JXL image a thousand times without deterioration :)
It sounds like the employed solution only modifies first element from [16,17] to [10,16].
At least this problem was highlighted by Kornel, one of the mozjpeg author here: https://github.com/mozilla/mozjpeg/issues/76
> the employed solution only modifies first element from [16,17] to [10,16].
Correction: 16 and 17 are values from the base tables, which means this table is used with q=50. With q=25 it will be [32, 22, 24, 28, 24, 20, 32, 28…] (in zigzag order). The employed solution is to always limit the first value by 10 regardless of q: [10, 22, 24, 28, 24, 20, 32, 28…]
mozjpeg chosen the different approach: it still scales all values based on q, but has significantly changed the default base table. It helps, but doesn't eliminate color banding completely (you can still see it on the example from issues/76).
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.
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).
In other words: end users use kraken, developers read this article.
I never really thought about how that "quality" slider worked (besides making the compression lossier), but it makes perfect sense now! It always amazes me how much I take for granted.
I always treat compression like a black box: "-crf 23" for H264, PNG and FLAC are nice but MP3 320s and 90+ "quality" JPEGs are good compromises, etc. And that's just for the stuff I deal with, there's no telling how much lossy compression goes on behind the scenes on my own computers, let alone all the stuff served up over the internet. There's so much lossy compression in the world, from EP speed on VHS tapes to websites reencoding uploaded images to every online video ever, it's crazy to think about.
Now could someone look at how video codecs can produce excellent high-detail scenes and motion in 4k resolution while at the same time making a blocky mess out of soft gradients, especially in dark scenes with slow movement?
But for pictures, JPEG is in its comfort zone and it's amazing it is still doing comparatively well after the IT equivalent of 150 years. Only now worthy alternatives are starting to emerge (looking at you JPEG XL), not for lack of trying (looking at you WEBP). It's incredible it managed to stay relevant for so long, and while surely patents, sunken cost fallacies, hardware implementations and inertia played a part, none of this would have mattered if it hadn't been pretty good to start with.
Considering that MPEG (and competitors) have evolved due to its deficiencies (the current baseline today is H.264 and not the original version H.261 or even its immediate successor MPEG-1), I'm surprised that JPEG is just showing its deficiencies today and not in 2000. Actually, it's a complement that although multiple file formats were invented to handle lossy pictures but even WebP can't beat JPEG all the time (especially that WebP can only save up to 16k pixels per side while JPEG can handle up to 64k pixels).
Lossy compression is not a bad thing. We need to get over this.
It's widely supported by vendors if you do not need to deal with IE: https://caniuse.com/?search=webp.
WebP is available for macOS 11, even with overlapping versions of Safari, but Apple relies on the OS image library to render some images and they haven't backported WebP supported when they updated Safari.
There is a space for JPEG and for PNG. Here is a good base reference https://www.a2hosting.com/blog/pngs-vs-jpegs/