Skip to content
This repository has been archived by the owner on Apr 21, 2023. It is now read-only.

Be less lossy for smaller image sizes #642

Open
GoogleCodeExporter opened this issue Apr 6, 2015 · 2 comments
Open

Be less lossy for smaller image sizes #642

GoogleCodeExporter opened this issue Apr 6, 2015 · 2 comments

Comments

@GoogleCodeExporter
Copy link

From Ed's mail:
"Ziproxy has a nice filter configuration for image recompression which takes 3 
quality options for 3 different image sizes.  The point of this is that it's 
sensible to apply more conservative recompression to small assets such as icons 
(where the large loss of quality isn't usually worth the 10 bytes saved...), a 
moderate compression to thumbnail sized images and often a slightly more 
aggressive compression to large pictures. Empirically this works very nicely 
with regards to maximising size vs quality and doesn't add much complexity to 
implementation."

We do something like this for the progressive/non-progressive transition in 
jpeg.  Best would be to choose quality based on image area, with most of the 
tail at the selected quality, and quality rising to 100 and/or switching to png 
as image area drops.  We should explicitly *avoid* adding extra configuration 
hooks here if we can, and instead base such a curve on actual measurements (eg 
predicted change in image size) as we did with the progressive / 
non-progressive decision.

The plus side to doing this is we'll get better-looking smaller images at 
minimal bandwidth cost, and may be able to decrease large-image quality a tad.  
If that's true we should come out ahead overall.

Original issue reported on code.google.com by jmaes...@google.com on 10 Mar 2013 at 1:57

@GoogleCodeExporter
Copy link
Author

Original comment by jmara...@google.com on 11 Mar 2013 at 6:59

  • Changed state: Accepted

@GoogleCodeExporter
Copy link
Author

I agree (strongly) to reducing knobs in principle, however, I think this is a 
situation where quality improvements can come from using different parameters 
on different size/shape images.  Either that can be done by taking a base 
quality number and tweaking it based on image size, or probably for 
development, it's helpful to have some manual tunables and tweak them.  

I do agree that many users will just want to enter a single number, so please 
support just being able to put in either a single param, or [3] params. In the 
case of a single param it would either apply to all image sizes, or would be 
applied based on a pre-defined ratio to all other sizes.

Original comment by jmaes...@google.com on 12 Mar 2013 at 2:53

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant