-
-
Notifications
You must be signed in to change notification settings - Fork 119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make lossy optimisation idempotent #9
Comments
This can be solved by setting some reasonable default value to "threshold", like 1%. At current defaults jpegoptim will try to optimize if there's even a 0.01% gain or less. This means almost zero savings in size, but clearly loss in quality. |
I don't how to achive this technically, but this would be awesome to have. I would love to just dumbly run |
Doesn't the --treshold option pretty much allow doing this? Something like: "-m95 -T1" (or "--max=95 --treshold=1") |
Oh, yeah, yes it does! I can sometimes re-run with same @CasperVector i think you can close this... |
I checked in change 8c68bac that changes --treshold option to accept decimal numbers as parameters. So it now should work specifying |
jpegoptim's lossless optimisation is idempotent, which can be extremely helpful under certain circumstances. However, its lossy optimisation (in the same quality settings) is not (always) idempotent, which causes the loss to accumulate after optimising multiple times, therefore it would be very nice if this could be fixed.
According to my personal test on several hundreds of images, after being optimised once in 95 quality, roughly half of the images would readily get optimised the second time in 95 quality; however, none get optimised if the quality is set to 96 the second time. So it seems that idempotency can be achieved by checking the quality of the image in concern, and using loseless optimisation if the quality is already no more than (or less than, if quality is set to 100) the user-defined threshold. I think idempotency could be an optional feature in jpegoptim, and users could enable it via some command line options.
The quality of the image is not written in the header, but could be determined from the quantisation table (cf. the
JPEGSetImageQuality
function from ImageMagick). I admit that ImageMagick is a huge dependency if you choose to link to it rather than incorporating the routine in jpegoptim; in that scenario, it might be a good choice to make ImageMagick a (build-time) optional dependency.The text was updated successfully, but these errors were encountered: