jpegoptim
jpegoptim copied to clipboard
tjko
Make lossy optimisation idempotent
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.
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 jpegoptim on all of my photos with cron or something, and just get new photos compressed and old (already-compressed) ones left as-is
Doesn't the --treshold option pretty much allow doing this?
Something like: "-m95 -T1" (or "--max=95 --treshold=1")
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 :+1:
@CasperVector i think you can close this...
I checked in change 8c68bac5ad1904c52f0369a0a49724b56b7d7cbe that changes --treshold option to accept decimal numbers as parameters. So it now should work specifying -T0.5 ?