It seems as if an older version of jpegtran produced smaller lossles jpg files

[FredWahl]

I have created a program that loops through a given folder and runs jpegtran on every jpg file it finds. If I get an output file and it is smaller than the input jpg, then it overwrites the input file. Below are the arguments that I use for which I expect lossless reduction

-optimize -progressive -copy none -outfile "F:\pictures\optimised.tmp" "F:\pictures\Image00.jpg"

I ran it on files that had been optimised by that older version, actually only one file which came out larger than the input jpg. Very unexpected, I thought it would be same size.
I haven’t tested if this true for the other files as well. I know for sure that I ran the older version for rhe files in this particular folder.

Therefore, I wonder if I’m doing something wrong or if it’s normal to sometimes get optimised pictures that are larger. After all it could be so if jpegtran repairs the file if it doesn’t have a marker that it should in which case I should accept the output file as better albeit larger. If jpegtran repairs files then I think the return value should indicate success and repaiired.

Btw I have noticed that some jpg files lack the marker that indicates height and width which van be opened anyway. Is ther any open source programs that takes can fix this and similar problems?

[FredWahl]

I ran jpegtran on other files, some of which got smaller. I didn’t check for exactly the same file size. But some got larger and I wonder why. Did jpegtran create a better jpg?

[FredWahl]

Using jpegsnoop, I have found that the huffman table and the SOS marker is different on the files that got larger. I had run an older version of jpegtran on these files. I now think that if jpegtran returns 0, I should accept this file as better even of it’s slightly larger.