Optimize compression quality levels by image size

[adamsilverstein]

Currently WordPress uses the same default quality setting for all image sub sizes. We are currently in the process of enabling quality settings on a per-size bases in https://core.trac.wordpress.org/ticket/54648. We should consider if it makes sense to adjust the defaults that WordPress uses for specific (default) sizes, based on best practices.

For example it may make sense to reduce the default quality setting for thumbnail images. (ref). Curious what other ideas people have for how to apply quality settings at different image sizes.

This is related to the work in https://github.com/WordPress/performance/issues/7 where we are investigating the best compression setting to use as our defaults for WebP (and figuring out a good way to reproduce/automate that testing).

[dainemawer]

I think this proposal has some legs @adamsilverstein - Im wondering how this would affect @2x and @3x screen pixel densities? Theres no way at this point to target quality per screen-density, unless we used a CSS media query which isn't going to help us much here.

Reducing quality may look okay on your average screen / laptop - but if image quality was reduced, Apple users would probably get a less than ideal experience - especially considering they are so used to seeing high quality / crystal clear images using Retina technology.

Adding the @2x modifier to images whose quality is not adjusted could be the work around here, so that they are served to Retina devices - but that creates yet another image file on the server.

Im not intimately familiar with how WordPress handles images but we should ideally look as "Downscaling" rather than "Upscaling" meaning that we should encourage users to rather upload a far more high quality image say @3x so that WordPress can do the hard work of downscaling for the best results possible, using platforms as a guide for quality. That may be happening to an extent already - but it;s not always clear as users tend to worry about uploading massive images.

The above also plays directly into the hands of: https://web.dev/serve-images-with-correct-dimensions/ where images should be scaled via their aspect ratio, not hard cropped per se.

Bit of a ramble there, but maybe it will provide some insight

[erikyo]

hi @dainemawer,

Reducing quality may look okay on your average screen / laptop - but if image quality was reduced, Apple users would probably get a less than ideal experience - especially considering they are so used to seeing high quality / crystal clear images using Retina technology.

I sincerely think it is not so, rather the opposite... Adopting a different quality setting for resizes allows you to serve hdpi images that weigh as much as their mdpi counterpart. You should take a look at the ticket with a >= 4k monitor, there are two images that demonstrate that even if there are more artifacts in the hdpi image (due to higher compression) these are "hidden" by the higher resolution. There is a wide literature on the internet about this "trick" for example this post or this. On the other hand apple users will download images faster, which will make their experience better than before.

Adding the @2x modifier to images whose quality is not adjusted could be the work around here, so that they are served to Retina devices - but that creates yet another image file on the server.

The proposal was to limit the quality of resizes that are certainly wider than a monitor, >2000px for example, assuming that these will never be displayed at 100% of their size (for this there is the "full" or the future "original image"). But this does not exclude your idea, indeed it would be nice to be able to create resizes for hdpi displays, because actually it isn't possible.

[mxbclang]

@mitogh Is it okay to assign this one to you since it's related to #204?

[mitogh]

I think this one might be more appropriate to assign to @getsource since he is working on this one.

[getsource]

Thanks for this! Yes, the reports I'm generating for #7 should directly apply here, at least for WebP.

I changed the image quality testing script so that it generates the sample images based on the sizes WordPress generates by default, and I'm hoping that should give us a pretty good idea of what they should be DSSIM-wise.

When I get that generated, I'll share here.

It may not tell the whole story for high DPI, but it's a start anyway.

[getsource]

I posted some related reports over in https://github.com/WordPress/performance/issues/7#issuecomment-1063590918 :

Imagick GD

The last tab (“Quality Settings for JPEG 83”) is the most helpful for the purposes of this issue, I think.

It has all of the sizes that WordPress creates by default, at WP’s default JPEG quality, with a suggested WebP closest quality, and percentage of file-size saved for each of the tested images.

As mentioned over there, I think it still needs at least a line art example to be a bit more definitive, but I like where the report ended up. I'll update here again when I've run it with more / different samples.

If anyone has some recommendations for either a small, but varied sample set, or a single high resolution line art and/or text image they've found useful in testing, it'd be appreciated.

[erikyo]

if you need there are some image that can be useful to check compression artifacts / degradation etc https://sourceforge.net/projects/testimages/files/

[BezPowell]

I haven't used wordpress regularly in a while, so am rather late to this discussion, but was just wondering whether it has ever been considered to use some kind of perceptual image optimizer like jpeg-recompress or pio in wordpress?

Quite a few studies, such as Johannes Siipola's excellent piece Is WebP really better than JPEG? have shown that the same quality setting in lossless formats such as Jpeg and Webp can result in output images with wildly differing SSIM scores depending on the source image (e.g. photos with heavily blurred backgrounds can often be encoded with a much lower quality setting than highly detailed images, without any loss in perceptual quality). As a result of this, finding a “one size fits all” encoding level always involves some compromise; either encoding low detail images at a higher file size than necessary, or losing quality in high detail images in order to reduce filesize.

Projects such as jpeg-recompress try to overcome this by encoding each image multiple times, and selecting the smallest output that is over a specified SSIM score. The downside, of course, is that each image has to encoded several times, but the advantage is that you can maintain a fairly high image quality while still keeping filesizes as small as possible. As images are generally encoded once, but sent to clients many times, this is often a worthwhile tradeoff.

I’ve been using jpeg-recompress as a post-processing step on a number of static websites for a few years and the results are very impressive indeed. Effectively, for a small increase in build time, I get to tailor the output quality for each individual image. I realise this can put quite a bit of extra strain on the server, and would introduce some extra dependencies, but think it would be well worth investigating; especially for sites with lots of traffic.