Adjust quantization tables for high-resolution displays

[kornelski]

There is a trick used when compressing images for high-DPI ("Retina") displays: because details are less visible in higher resolution (or when resampled on lower-resolution displays), the image can tolerate higher level of compression.

http://filamentgroup.com/lab/compressive-images.html http://gogrowstrategies.com/compressive-images/

Unfortunately in libjpeg the quantization tables are derived from default tables by proportionally scaling all coefficients.

The problem with that is that very low quality settings cause DC to be quantized too heavily, virtually guaranteeing that the image will look blocky and posterized. Giving bits to ACs can't help if the DC is awful.

My suggestion is:

• Tweak the algorithm in jpeg_add_quant_table to quantize DC and the first few ACs less when the quality is very low.
• Add a switch to cjpeg for optimization for high-dpi displays. It'd adjust quality scale (lower the quality), quantization tables (protect DC from getting too blocky) and perhaps adjust the lambda for trellis.

The implementation I've done https://github.com/pornel/mozjpeg/commit/615652b81a8e93c50d5ec72a0f1a29e5af71ee1e just increases DC and the first few ACs. It does work, but maybe an even more elegant approach would be to devise quantization tables optimized for low and high qualities and crate final quantization table from interpolation between these tables.

[pdknsk]

I'm not too familiar with how JPEG works, so just a general comment. This works, unless the image has gradients.

[kornelski]

Mozjpeg:

With this change: https://github.com/pornel/mozjpeg/commit/615652b81a8e93c50d5ec72a0f1a29e5af71ee1e

[kornelski]

Resized to simulate downsampling on "@1x" screens:

From dssim tool (lower is better):

• 0.031151 standard DC
• 0.023471 improved DC

[dwbuiten]

@pornel On my high DPI display, the 2nd image (with your change) is different, but not better IMO. The sky gradients are less mangled, but the rocks and plants are much worse.

[kornelski]

@dwbuiten in the posterized image rocks and plants look more interesting due to color shifts and increased saturation, but that is actually also an error in the image. The bland version is actually closer to the original: http://optipng.sourceforge.net/pngtech/corpus/kodak/kodim21.png

[danielgtaylor]

My subjective view is that the image after @pornel's change looks better. :+1:

[dwbuiten]

@pornel Looks like firefox was mucking with the image. Viewing in a proper image viewer indeed shows it looks better. Apologies.

[bdaehlie]

What exactly does "firefox was mucking with the image" mean? If there is a bug in Firefox we should file it. The only thing I've noticed about how Firefox renders images that is sub-optimal is that most browsers assume sRGB for JPEGs without a colorspace, Firefox doesn't. This is bad for compatibility, and the sRGB guess is correct more often than not.

[dwbuiten]

@bdaehlie On high DPI displays, firefox upsamples by default (as it should), but it doesn't do it so well with this set (it used to be bilinear, might be bicubic now -- there is a bug open or opened about changing it to lanczos... at least downsampling was fixed recently.)

The best way I can kind of explain it is that the discoloration in the original image near the rocks, after upsampling, looked to be a more similar complexity to the original image to my eye (psychovisual effect -- the eye tends to prefer similar complexity to the source image than blurred, but more similar). It could also just be that my taste is biased.

Sorry for the noise.

[bdaehlie]

No worries, I just want to make sure any major issues with Firefox's rendering get reported and fixed.

[kornelski]

cjpeg -quant-table 2 (#84) is now close enough, so I'm closing this issue.