1
I ran jpegtran on a bunch of images as such:
$ jpegtran -copy none -optimize
Most of them were reduced in size by a lot. But some of them actually increased in size. How can that be?
1
I ran jpegtran on a bunch of images as such:
$ jpegtran -copy none -optimize
Most of them were reduced in size by a lot. But some of them actually increased in size. How can that be?
1
The -optimize
flag will "Perform optimization of entropy encoding parameters" (directly take from the jpegtran
manual), which says nothing about the size of the result. If the source image file doesn't contain any comments or other "excess baggage" that is removed by -copy none
, then I see no reason why the file could not grow in size by a fraction.
I see one good reason why the file should not grow in size - the whole point of using jpegtran's "optimize" flag! There's nothing optimal about a larger file! It could not be adding anything of value to it, not extra detail to the image of free tickets to the opera or anything else. As the commenter said, jpegtran should leave the original image as is, if its "optimization" is sub optimal. Overall, I saved a huge amount of disk space (something over 60 maybe 70%), but it probably would have been a few % more if that simple check had been made. – Buttle Butkus – 2015-06-03T22:38:37.820
The jpegtrans
manual refers to the manual of cjpeg
for more info about the -optimize
flag. It says "-optimize
usually makes the JPEG file a little smaller". Although it actually mentions the size of the image, it definitely makes no promises. I think that the savings that you make from using the flag will be insignificant (or at least much smaller) than the savings that you make from removing EXIF tags etc. with -copy none
. – Kusalananda – 2015-06-04T08:06:33.813
Perhaps I will try using -optimize
without -copy none
and see which one contributed more to the savings I saw. By the way, you misspelled optimize
at the start of your post (you missed the "p"). – Buttle Butkus – 2015-06-06T00:31:11.963
1
Probably because the Huffman tables were already optimal and jpegtran didn't recognise that? (It should ideally discard the larger version in that case so if it didn't you should report a bug.) There are lots of other utils you can try instead.
– Karan – 2015-06-03T08:27:36.487