> MozJPEG use a lower value in the first position of the quantization just like this article suggests
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.
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?
It was not badly picked for regular use cases. Just, before the retina displays appeared no one was interested in extreme low bitrate and no one knew that different artifacts had different impact with high density.
> 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).
Each resampling algorithm will internally produce some high-precision result before cutting it to 8 bits. For Pillow-SIMD it is 32-bit integers. Currently, I haven't considered dithering, but it is a very interesting idea. Do you have any links for further reading about downsampling banding and dithering?
About IPP's features: the comparison is pretty fair: the same input, the same algorithm and filters, pretty much the same output. If IPP uses more resources internally with the same output, so, maybe it shouldn't.
Shame on me, I still haven't added the link to IPP's test file I used. Here is it: https://gist.github.com/homm/9b35398e7e105a3c886ab1d60bf598d...
It is modified ipp_resize_mt program from IPP's examples. If you have installed IPP, you'll easily find and build it.
Well, 3680x2456 / 0.06 seconds ≈ 150 Mp/s or 75 Mp/s/per core. Pillow-SIMD's current implementation runs on ≈ 700 Mp/s/pre core for bicubic (which is closer to this implementation).
Obviously, your implementation could be further optimized, but quality drawbacks will remain the same.
Color space conversion is a hard topic in terms of performance. First of all, not all images are stored in sRGB. Most of them have another color profiles (such as P3 or ProPhoto). So, sRGB conversion is not enough, you need the full color management.
Second, you'll see a real profit of color management only on a few images. Most time you'll see the difference only when you see both images at the same time on the same screen.
For now, I came up to the resizing in original non-linear color space and saving the original color profile with the resulting image.
It originally was written two years ago, so some things have changed. But in general, it is still correct: for most browsers, you need to combine several ugly technics to get suitable results. Though, the quality will have nothing common with quality when you have direct access to hardware.
Opencv doesn't provide convolution-based resampling. Only supersampling with INTER_AREA flag, which is comparable to BICUBIC for high-ratio downscaling. So, such statements don't make sense without exact code :-)
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.