Page 1 of 1
"Optimized" image heavier (bigger file size) than the original
Posted: 2017-04-26T10:27:48-07:00
by 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?
:_
Re: "Optimized" image heavier (bigger file size) than the original
Posted: 2017-04-26T11:04:41-07:00
by fmw42
Your original image has quality 69. In your command set the quality the same just before writing the output jpg. Does that help?
Re: "Optimized" image heavier (bigger file size) than the original
Posted: 2017-04-26T11:22:15-07:00
by snibgo
cyttorak wrote: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.
Re: "Optimized" image heavier (bigger file size) than the original
Posted: 2017-04-26T11:44:15-07:00
by cyttorak
fmw42 wrote: ↑2017-04-26T11:04:41-07:00
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?
Re: "Optimized" image heavier (bigger file size) than the original
Posted: 2017-04-27T11:43:41-07:00
by 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).
Re: "Optimized" image heavier (bigger file size) than the original
Posted: 2017-04-28T02:41:08-07:00
by cyttorak
glennrp wrote: ↑2017-04-27T11:43:41-07:00
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.
Re: "Optimized" image heavier (bigger file size) than the original
Posted: 2017-04-28T09:27:57-07:00
by 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.
Re: "Optimized" image heavier (bigger file size) than the original
Posted: 2017-04-28T12:55:50-07:00
by glennrp
cyttorak wrote: ↑2017-04-28T02:41:08-07:00
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.
Re: "Optimized" image heavier (bigger file size) than the original
Posted: 2017-04-29T13:25:45-07:00
by cyttorak
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)
fmw42 wrote: ↑2017-04-28T09:27:57-07:00Please 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
Re: "Optimized" image heavier (bigger file size) than the original
Posted: 2017-04-29T13:40:33-07:00
by snibgo
Commands are executed in the order you give.
cyttorak wrote:-fuzz 600 -format "%@\n"
Fuzz is a setting that is used in the virtual trim. So that works.
cyttorak wrote:-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.
Re: "Optimized" image heavier (bigger file size) than the original
Posted: 2017-04-29T14:06:37-07:00
by cyttorak
snibgo wrote: ↑2017-04-29T13:40:33-07:00you 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?
Re: "Optimized" image heavier (bigger file size) than the original
Posted: 2017-04-29T14:19:15-07:00
by 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.
Re: "Optimized" image heavier (bigger file size) than the original
Posted: 2017-04-29T14:26:40-07:00
by 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.
Re: "Optimized" image heavier (bigger file size) than the original
Posted: 2017-04-29T14:38:26-07:00
by cyttorak
But 02-CROP.jpg would have a file size smaller than original.jpg, now that I'm croping in 16x16 blocks, or not?
Re: "Optimized" image heavier (bigger file size) than the original
Posted: 2017-04-30T08:22:18-07:00
by 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.
