Legacy ImageMagick Discussions Archive

Hi,

I have noticed a strange behavior in imagemagick (version 6.5.7-8 2010-12-02 Q16 and
version 6.6.0-4 2011-06-15 Q16 ), in which cropping an image will result in a increased filesize.

Edit: The problem commented here seems to be solved. Read this response for more information.

I have a big set of of grayscale images like this:
http://www.jespa.es/imageMagickQuestion/original.jpg

This is a grayscale 5345x2793 jpeg and its filesize is 398 Kb. It has about 15 Mpixels.

I am not sure of the quality value of the image, so I do a conversion to a known value of quality with the command: The result image is here and its filesize is 390 Kb, which is similar to original.

The strange behavior comes when I try to crop the image to trim the borders with the command: So I get this file which dimensions 3550x2600 (about 9 Mpixels) and its filesize is 473 Kb. That's more than the file with the same quality and 15 Mpixels. The result is the same if I crop from the convert_quality80.jpg file.

Any idea of why the cropped file need more disk space to store less Mpixels? I have thousands of similar images and need to reduce disk space.

I have let the output of "identify -verbose" for each file in this directory.

Thanks.

I suspect that mainly you are cropping out flat black which does not contribute to the file size after compression. Why it increases some is likely due to the decompression and recompression and possibly that it is not on "tile" boundaries. But I am not an expert on JPG compression, so will defer to any expert on this.

Try on a different image that does not have lots of constant color regions.

Yes, I suppose that is something about jpg recompresion... in fact, I have discover something that is even more surprising:

If I run the commands I will get two very similar images, with same dimensions and only differing by 1 pixel column, but...
q80_crop800.jpg takes 274K
q80_crop801.jpg takes 430K

The "secret" here is that cropping a boundary with size multiply of 8 will remove a complete set of 8x8 blocks used in .jpg algorithm, and the result will compress with the same loss of the original file. Using a crop that is not multiply of 8 will break every 8x8 block.

So, to whom it may concern, there is a golden rule here:
When cropping from a .jpg file, try to use always an offset that is multiply of 8, so the jpeg compression can reuse the original 8x8 blocks

I will let some examples of cropped files here to illustrate the rule. It's so important for me, that I suggest to comment this rule in the documentation of the crop command.

Thanks fmw42 for your response.

Note however that IM uncompress and re-compress images. As such this file size changes (and degrading) will happen.

Also the crop should be a multiple of 8 pixels from the top-left corner only for that rule to apply, though I suppose that is implied.

Finally if you are going to crop in multiples of 8 and want to avoid this uncompress/re-compress cycle, then you can use specialised lossless JPG processing (not a part of ImageMagick). For more information and links see...
http://www.imagemagick.org/Usage/formats/#jpg_lossless

The actual command is the more advanced version of "jpegtrans" from
http://www.jpegclub.org/
though "jhead" can do this in a more friendly manner.
http://www.sentex.net/~mwandel/jhead/


ASIDE: actually this is units of 8 or 16 depending on the -sampling-factor being used. 1=8pixels 2=16pixels.

jespa wrote: It's so important for me, that I suggest to comment this rule in the documentation of the crop command.

It applies not just to crop but to any command that changes the left and/or top boundary of the image (chop, trim, shave, etc.) so it might make more sense to put a comment in the documentation of the JPEG format instead.

I have added the following to the introduction of JPEG Image Format
http://www.imagemagick.org/Usage/formats/#jpg

This lossy behaviour becomes even more noticable if a JPEG image is changed so that the top or left boundary is not a multiple of 8. When this happens the JPEG compression 'blocks' or 'cells' will be completely different, and that can produce a large increase in the final image save size.

That is operations such as chop, trim, shave, border, frame, extent, etc.. (See Cutting and Bordering Operations) that can shift the image data by a pixel offset that is not a 8. </P>

See the IM Forum discussion "Cropping an image result in an unexpected increased file" for more details.

With appropriate links of course. (appear in an hour or too)

Great!
Thanks by taking the time to update the documentation.

anthony wrote:I have added the following to the introduction of JPEG Image Format
http://www.imagemagick.org/Usage/formats/#jpg

This lossy behaviour becomes even more noticable if a JPEG image is changed so that the top or left boundary is not a multiple of 8.

More precisely, "...changed so that the amount of change to the top or left boundary is not a multiple of 8"

Done. (give it an hour or so to get though web server caches).