Cropping an image result in an unexpected increased filesize

Questions and postings pertaining to the usage of ImageMagick regardless of the interface. This includes the command-line utilities, as well as the C and C++ APIs. Usage questions are like "How do I use ImageMagick to create drop shadows?".
Post Reply
jespa
Posts: 4
Joined: 2012-02-28T08:34:32-07:00
Authentication code: 8675308

Cropping an image result in an unexpected increased filesize

Post by jespa » 2012-02-28T09:18:38-07:00

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:

Code: Select all

convert original.jpg -quality 80 convert_quality80.jpg
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:

Code: Select all

convert original.jpg -quality 80 -crop 3550x2600+750 +repage convert_quality80_crop3550x2600.jpg
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.
Last edited by jespa on 2012-02-28T14:29:05-07:00, edited 2 times in total.

User avatar
fmw42
Posts: 22101
Joined: 2007-07-02T17:14:51-07:00
Location: Sunnyvale, California, USA

Re: Cropping an image result in an unexpected increased file

Post by fmw42 » 2012-02-28T12:53:52-07:00

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.

jespa
Posts: 4
Joined: 2012-02-28T08:34:32-07:00
Authentication code: 8675308

Re: Cropping an image result in an unexpected increased file

Post by jespa » 2012-02-28T14:18:25-07:00

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

Code: Select all

convert original.jpg -quality 80 -crop 3550x2600+800 q80_crop800.jpg
convert original.jpg -quality 80 -crop 3550x2600+801 q80_crop801.jpg
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.

User avatar
anthony
Posts: 8869
Joined: 2004-05-31T19:27:03-07:00
Authentication code: 8675308
Location: Brisbane, Australia

Re: Cropping an image result in an unexpected increased file

Post by anthony » 2012-02-28T17:25:41-07:00

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.
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
http://www.imagemagick.org/Usage/

User avatar
glennrp
Posts: 1163
Joined: 2006-04-01T08:16:32-07:00
Location: Maryland 39.26.30N 76.16.01W

Re: Cropping an image result in an unexpected increased file

Post by glennrp » 2012-02-29T08:31:34-07:00

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.

User avatar
anthony
Posts: 8869
Joined: 2004-05-31T19:27:03-07:00
Authentication code: 8675308
Location: Brisbane, Australia

Re: Cropping an image result in an unexpected increased file

Post by anthony » 2012-02-29T19:21:59-07:00

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)
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
http://www.imagemagick.org/Usage/

jespa
Posts: 4
Joined: 2012-02-28T08:34:32-07:00
Authentication code: 8675308

Re: Cropping an image result in an unexpected increased file

Post by jespa » 2012-03-01T04:35:25-07:00

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

User avatar
glennrp
Posts: 1163
Joined: 2006-04-01T08:16:32-07:00
Location: Maryland 39.26.30N 76.16.01W

Re: Cropping an image result in an unexpected increased file

Post by glennrp » 2012-03-01T06:27:35-07:00

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"

User avatar
anthony
Posts: 8869
Joined: 2004-05-31T19:27:03-07:00
Authentication code: 8675308
Location: Brisbane, Australia

Re: Cropping an image result in an unexpected increased file

Post by anthony » 2012-03-01T20:06:51-07:00

Done. (give it an hour or so to get though web server caches).
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
http://www.imagemagick.org/Usage/

Post Reply