"Optimized" image heavier (bigger file size) than the original

[cyttorak]

Hello

I'm trying trim and optimize this image this image http://www.revista.lamarea.com/wp-conte ... 7/03/h.jpg without resizing or changing his format but most of times I got a heavier image.

This is the image (I have renamed it as original.jpg):

Code: Select all

u@h ~/d $ wget http://www.revista.lamarea.com/wp-content/uploads/2017/03/h.jpg --quiet -O original.jpg
$ ls -lh original.jpg 
-rw-rw-r-- 1 u u 2.2M Mar 27 22:41 original.jpg
u@h ~/d $ identify -verbose original.jpg 
Image: original.jpg
  Format: JPEG (Joint Photographic Experts Group JFIF format)
  Mime type: image/jpeg
  Class: DirectClass
  Geometry: 4000x10500+0+0
  Resolution: 100x100
  Print size: 40x105
  Units: Undefined
  Type: TrueColor
  Endianess: Undefined
  Colorspace: sRGB
  Depth: 8-bit
  Channel depth:
    red: 8-bit
    green: 8-bit
    blue: 8-bit
  Channel statistics:
    Pixels: 42000000
    Red:
      min: 0 (0)
      max: 255 (1)
      mean: 243.25 (0.953921)
      standard deviation: 37.0469 (0.145282)
      kurtosis: 18.0869
      skewness: -4.16267
    Green:
      min: 0 (0)
      max: 255 (1)
      mean: 242.074 (0.949308)
      standard deviation: 40.0665 (0.157124)
      kurtosis: 15.9259
      skewness: -3.94768
    Blue:
      min: 0 (0)
      max: 255 (1)
      mean: 240.894 (0.94468)
      standard deviation: 43.0608 (0.168866)
      kurtosis: 13.7872
      skewness: -3.73882
  Image statistics:
    Overall:
      min: 0 (0)
      max: 255 (1)
      mean: 242.072 (0.949303)
      standard deviation: 40.1332 (0.157385)
      kurtosis: 15.8425
      skewness: -3.94893
  Rendering intent: Perceptual
  Gamma: 0.454545
  Chromaticity:
    red primary: (0.64,0.33)
    green primary: (0.3,0.6)
    blue primary: (0.15,0.06)
    white point: (0.3127,0.329)
  Background color: white
  Border color: srgb(223,223,223)
  Matte color: grey74
  Transparent color: black
  Interlace: None
  Intensity: Undefined
  Compose: Over
  Page geometry: 4000x10500+0+0
  Dispose: Undefined
  Iterations: 0
  Compression: JPEG
  Quality: 69
  Orientation: Undefined
  Properties:
    date:create: 2017-04-26T18:31:37+02:00
    date:modify: 2017-03-27T22:41:34+02:00
    jpeg:colorspace: 2
    jpeg:sampling-factor: 2x2,1x1,1x1
    signature: b778723dafd07abb245122ae3ecce35c6d512103ac916e82050da40c67ea01d9
  Profiles:
    Profile-app12: 15 bytes
  Artifacts:
    filename: original.jpg
    verbose: true
  Tainted: False
  Filesize: 2.257MB
  Number pixels: 42M
  Pixels per second: 48.28MB
  User time: 0.860u
  Elapsed time: 0:01.870
  Version: ImageMagick 6.8.9-9 Q16 x86_64 2017-03-14 http://www.imagemagick.org

These are my attempts:

Code: Select all

u@h ~/d $ convert original.jpg -strip +repage -trim -fuzz 600 01-TRIM.jpg
u@h ~/d $ convert original.jpg -strip +repage -trim -fuzz 600 -colors 32 02-TRIM-COLORS-32.jpg
u@h ~/d $ convert original.jpg -strip +repage -trim -fuzz 600 -colors 32 -quality 60 03-TRIM-COLORS-32-QUALITY-60.jpg
u@h ~/d $ ls -lh *.jpg 
-rw-rw-r-- 1 u u 2.2M Apr 26 18:49 01-TRIM.jpg
-rw-rw-r-- 1 u u 2.5M Apr 26 18:51 02-TRIM-COLORS-32.jpg
-rw-rw-r-- 1 u u 2.2M Apr 26 18:54 03-TRIM-COLORS-32-QUALITY-60.jpg
-rw-rw-r-- 1 u u 2.2M Mar 27 22:41 original.jpg
u@h ~/d $ ls -l *.jpg 
-rw-rw-r-- 1 u u 2298003 Apr 26 18:49 01-TRIM.jpg
-rw-rw-r-- 1 u u 2592610 Apr 26 18:51 02-TRIM-COLORS-32.jpg
-rw-rw-r-- 1 u u 2270907 Apr 26 18:54 03-TRIM-COLORS-32-QUALITY-60.jpg
-rw-rw-r-- 1 u u 2256783 Mar 27 22:41 original.jpg
u@h ~/d $ identify -format "%k colors in %f\n" *.jpg
204286 colors in 01-TRIM.jpg
186954 colors in 02-TRIM-COLORS-32.jpg
195756 colors in 03-TRIM-COLORS-32-QUALITY-60.jpg
199575 colors in original.jpg
u@h ~/d $ identify -format "%Q quality value in %f\n" *.jpg
69 quality value in 01-TRIM.jpg
69 quality value in 02-TRIM-COLORS-32.jpg
60 quality value in 03-TRIM-COLORS-32-QUALITY-60.jpg
69 quality value in original.jpg

I can't understand:

• Why 01-TRIM.jpg have more colors than original.jpg?

• Why all "optimized" image have bigger file size than original.jpg?

• Why 02-TRIM-COLORS-32.jpg and 03-TRIM-COLORS-32-QUALITY-60.jpg don't have 32 colors?

• Why 03-TRIM-COLORS-32-QUALITY-60.jpg is bigger than 01-TRIM.jpg and 02-TRIM-COLORS-32.jpg?

• Why 03-TRIM-COLORS-32-QUALITY-60.jpg have more colors than 02-TRIM-COLORS-32.jpg?

:_

[fmw42]

Your original image has quality 69. In your command set the quality the same just before writing the output jpg. Does that help?

[snibgo]

Why 02-TRIM-COLORS-32.jpg and 03-TRIM-COLORS-32-QUALITY-60.jpg don't have 32 colors? etc

JPG is a lossy compression format. This means many pixel values will slightly change. This almost always increases colours, especially when the input has areas of flat colours.

To get good compression from JPG, the image should be noisy. Smoother images (eg by reducing colours) have worse compression.

I can't see any point in reducing colors, then saving to jpg.

[cyttorak]

Your original image has quality 69. In your command set the quality the same just before writing the output jpg. Does that help?

In my examples, commands without -quality parameter preserve the quality 69. Also there is a example with -quality 60.
isn't it what you mean?

[glennrp]

Also bear in mind that when the -trim operation doesn't cut off an exact multiple of 8 columns or 8 rows, the image gets re-quantized into new 8x8 blocks (or 16x16 blocks, if sub-sampling), which can cause new colors to be created (by default, sub-sampling happens when the requested quality is less than 90).

[cyttorak]

Also bear in mind that when the -trim operation doesn't cut off an exact multiple of 8 columns or 8 rows, the image gets re-quantized into new 8x8 blocks (or 16x16 blocks, if sub-sampling), which can cause new colors to be created (by default, sub-sampling happens when the requested quality is less than 90).

Is there any way to preserve de multiplicity? I mean, trim in "8x8 blocks" steps, to avoid to do new blocks. I don't mind trim a little less pixels if the file size will be better.

[fmw42]

Is there any way to preserve de multiplicity? I mean, trim in "8x8 blocks" steps, to avoid to do new blocks. I don't mind trim a little less pixels if the file size will be better.

You could find the trim dimensions using %@ in string formats (see http://www.imagemagick.org/script/escape.php) and put it into variables. Then compute the next smaller multiple of 8 and use those with -crop.

Such coding is OS dependent.

Please always provide your IM version and platform, since syntax may differ.

[glennrp]

Is there any way to preserve de multiplicity? I mean, trim in "8x8 blocks" steps, to avoid to do new blocks. I don't mind trim a little less pixels if the file size will be better.

I don't know of a really simple way, but I've done it lots of times, for this very reason. It involves some bookkeeping to do a trial "-trim" and then adjusting to 8x8 or 16x16 block boundaries.

[cyttorak]

You could find the trim dimensions using %@ in string formats (see http://www.imagemagick.org/script/escape.php) and put it into variables. Then compute the next smaller multiple of 8 and use those with -crop

Ok, I have been reading viewtopic.php?t=30761
And I don't sure what is de proper way to estimate the trim dimension, becouse I get two different result with this two commands:

Code: Select all

u@h ~/d $ convert original.jpg -strip +repage -fuzz 600 -format "%@\n" info:
3562x8221+240+139
u@h ~/d $ convert original.jpg -strip +repage -trim -fuzz 600 -format "%wx%h+%[fx:page.x]+%[fx:page.y]\n" info:
3584x8224+232+136

But If I do that:

Code: Select all

u@h ~/d $ convert original.jpg -strip +repage -trim -fuzz 600 01-TRIM.jpg 
u@h ~/d $ identify -format "%wx%h\n" 01-TRIM.jpg 
3584x8224

It seem that the correct way is

Code: Select all

convert original.jpg -strip +repage -trim -fuzz 600 -format "%wx%h+%[fx:page.x]+%[fx:page.y]\n" info:

because this give me the same dimension (3584x8224) that 01-TRIM.jpg

Do you know why?

Aso, I can't understood why the first command give a smaller dimension (3562x8221+240+139) than the second command (3584x8224+232+136)

Please always provide your IM version and platform, since syntax may differ.

Code: Select all

u@h ~/d $ convert --version
Version: ImageMagick 6.8.9-9 Q16 x86_64 2017-03-14 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2014 ImageMagick Studio LLC
Features: DPC Modules OpenMP
Delegates: bzlib cairo djvu fftw fontconfig freetype jbig jng jpeg lcms lqr ltdl lzma openexr pangocairo png rsvg tiff wmf x xml zlib

u@h ~/d $ uname -m 
x86_64
u@h ~/d $ cat /etc/issue
Linux Mint 18.1 Serena \n \l

[snibgo]

Commands are executed in the order you give.

-fuzz 600 -format "%@\n"

Fuzz is a setting that is used in the virtual trim. So that works.

-trim -fuzz 600

Fuzz is a setting that would be used in the actual trim, but you set it after doing the trim, so it has no effect.

[cyttorak]

you set it after doing the trim, so it has no effect.

Thanks. That is

Code: Select all

u@h ~/d $ convert original.jpg -strip +repage -fuzz 600 -trim -format "%wx%h+%[fx:page.x]+%[fx:page.y]\n" info:
3562x8221+240+139
u@h ~/d $ convert original.jpg -strip +repage -fuzz 600 -format "%@\n" info:
3562x8221+240+139

So if I want to preserve 16x16 blocks, I have to do that:

240 % 16 = 0
139 % 16 = 11 ---> 139 - 11 = 128

So I have to crop since (240, 128) point

16 - (3562 % 16) = 6 ----> 3562 + 6 = 3568
16 - ((8221 + 11) % 16) = 8 ----> 8221 + 11 + 8 = 8240

So I have to crop a 3568x8240 section.

Then:

Code: Select all

u@h ~/d $ convert original.jpg -strip +repage -crop "3568x8240+240+128" 02-CROP.jpg 
u@h ~/d $ ls -l | sort
-rw-rw-r-- 1 u u 2256783 mar 27 22:41 original.jpg
-rw-rw-r-- 1 u u 2292677 abr 29 23:02 02-CROP.jpg
-rw-rw-r-- 1 u u 2298003 abr 29 22:12 01-TRIM.jpg
u@h ~/d $ identify -format "%wx%h %f\n" *
3584x8224 01-TRIM.jpg
3568x8240 02-CROP.jpg
4000x10500 original.jpg

Now, 02-CROP.jpg have less file size than 01-TRIM.jpg, but it is bigger file size than original.jpg

Where is the mistake?

[snibgo]

Predicting exactly how large a JPG will be isn't possible. But you can set a limit, eg:

Code: Select all

convert original.jpg -strip +repage -crop "3568x8240+240+128" -define jpeg:extent=2200000 x.jpg

x.jpg is 2,197,025 bytes.

[fmw42]

These three commands all give the same results:

Code: Select all

convert logo: -fuzz 10% -format "%@\n" info:

convert logo: -fuzz 10% -trim -format "%wx%h%X%Y\n" info:

convert logo: -fuzz 10% -trim -format "%wx%h%O\n" info:

457x472+92+0

I typically find it easier to express -fuzz in percent.

[cyttorak]

But 02-CROP.jpg would have a file size smaller than original.jpg, now that I'm croping in 16x16 blocks, or not?

[glennrp]

Your original file, according to "identify -verbose" has "Quality 69 (approximate)".
The "approximate" means that the quantization tables used weren't exactly those
used by ImageMagick, so the recompression won't be exactly the same. It's not
a mistake but simply a fact of life.