JPEG: Bigger file size after converting with less quality

[imagemarc]

Hi all,

I'm experiencing a strange behaviour with JPEG image compressing:
I want to regenerate a JPEG image setting a lower quality in order to reduce its file size:
convert -quality 85 original.jpg destination.jpg

When I execute the identify command with both images I get:
original.jpg - Quality: 92
destination.jpg - Quality: 85

Both images have the same "jpeg:sampling-factor": 1x1,1x1,1x1

The resulting image, having less Quality, turns to be BIGGER than the original one:
original.jpg :1,194,316 bytes
destination.jpg: 1,207,274 bytes

Does anybody have an explanation of this?
What can I do to reduce the Quality to get smalled sizes?
Maybe the "Quality" number is not a standard measure, and different applications interpret it differently?

Thank you very much,
Marcos

[dproc]

One possibility is that the distortions from one compression can appear as more detail to a subsequent compression.

Another thing to check is for any data being added to the exif and/or text comment blocks in the JPG file. I'm an IM noob so I don't know the switches to remove that data--assuming that's the problem. Many image editors let you remove that stuff. In a pinch you can also save as a lossless format that supports no extra data, then convert back to JPG by a utility that doesn't add any extra info. I've done this to reduce the size of web thumbnails, for example.

[imagemarc]

The problem is not with the extra header information (exif, etc): The size of this information is very small compared to the image itself, in my case.
If fact, I've tested removing the extra headers (f.y.i., the parameter in IM is "-strip"), and no significant change appeared.

Even considering that the distortions from one compression can appear as more detail to a subsequent compression, I think there is something else - it's sounds strange to me that decreasing the compression from 92 to 85 ends with a bigger file...
If I store the image with quality 8 in Photoshop, I get a file size of 1,758,083 bytes (with IM I get a file of 2,045,794 bytes!!)

[fmw42]

perhaps different compression techniques

also to be proper your syntax should be


convert original.jpg -quality 85 destination.jpg


look at the verbose information of both images and compare them using identify -verbose image

see what difference you see besides the quality level


Are you using Q16 or Q8 IM. If the former, try adding -depth 8 to your command to produce 8-bits per channel rather than 16-bits per channel

[imagemarc]

Thank you very much for the answer...

I already tested it setting the parameter "-depth 8".

I've also already compared the identify -verbose output, and the only significant difference is the Quality parameter (besides, of course, statistic values, the signature and dates).

Is it possible that the reason for this is the usage of different DCT tables when generating the JPEG?
Maybe Photoshop (or other application) generated the original JPEG with a DCT that obtains smaller files than the DCT used by IM (Huffman Optimized)?

Another option:
Maybe the Quality paramter cannot be compared directly from application to application?

Any clue??

Thanks!

[fmw42]

Is it possible that the reason for this is the usage of different DCT tables when generating the JPEG?
Maybe Photoshop (or other application) generated the original JPEG with a DCT that obtains smaller files than the DCT used by IM (Huffman Optimized)?

Another option:
Maybe the Quality paramter cannot be compared directly from application to application?

I imagine either are possible. But I am no expert on this issue.


see http://www.imagemagick.org/Usage/formats/#jpg and the link to JPG Compression Introduction

[WolfWings]

Maybe the Quality paramter cannot be compared directly from application to application?

A quick test (if you have a Windows box to check with) is to grab the jpegtran tool from jpegclub.org, and do a lossless recompression with that to standardize everything except the DCT tables between the two image files. One encoder might be doing progressive (which frequently/nearly-always generates smaller files) while the other is only doing one-pass huffman-optimized, for example.

Compare running your original file and imagemagick file through jpegtran with identical output settings, no cropping, and then compare filesizes.

[anthony]

Note that JPEG quality is not uniform from one implementation to another. It is more of a guide to the lassy compression utility than a standard. It is also very difficult to tell what the compression is on an existing image.

So how do you know the input images compression was 92?

[albumarch]

Thank you all for the responses.

I will check the jpegtran tool and see what I figure out...

I know the original compression is 92 because I get from the "identify -verbose" command.