Skip to content
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

Closed
CasperVector opened this issue Nov 23, 2013 · 5 comments
Closed

Make lossy optimisation idempotent #9

CasperVector opened this issue Nov 23, 2013 · 5 comments

Comments

@CasperVector
Copy link

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.

@varnav
Copy link

varnav commented May 26, 2022

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.

@TheLastGimbus
Copy link

TheLastGimbus commented Aug 19, 2022

I don't how to achive this technically, but this would be awesome to have. I would love to just dumbly run jpegoptim on all of my photos with cron or something, and just get new photos compressed and old (already-compressed) ones left as-is

@tjko
Copy link
Owner

tjko commented Aug 22, 2022

Doesn't the --treshold option pretty much allow doing this?

Something like: "-m95 -T1" (or "--max=95 --treshold=1")

@TheLastGimbus
Copy link

Doesn't the --treshold option pretty much allow doing this?

Oh, yeah, yes it does! I can sometimes re-run with same -m again, and it makes some optimizations more (1-5%), but after that it's like 0.5%, so -t would be good 👍

@CasperVector i think you can close this...

@tjko
Copy link
Owner

tjko commented Jan 2, 2023

I checked in change 8c68bac that changes --treshold option to accept decimal numbers as parameters. So it now should work specifying -T0.5 ?

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

No branches or pull requests

4 participants