|
Some details on the JPEG compression results :
I used the ImageMagick 'identify' command to examine the
properties of the JPEG files after using 'convert' with the
'-sampling-factor' option.
The 'identify' command revealed that when I used
'-sampling-factor 2x2' the result was:
jpeg:sampling-factor: 2x2,1x1,1x1
for the luminosity and two color channels.
And when I used '-sampling-factor 1x1' the result was:
jpeg:sampling-factor: 1x1,1x1,1x1
'2x2' gave better compression than '1x1', on JPEG files.
In the future, I will tend to use '2x2' rather than '1x1'
in any further image compression experiments.
In fact, '2x2' is the default 'sampling-factor' used by the
ImageMagick 'convert' command if the '-sampling-factor'
parameter is not used with an input JPEG file.
My experiments above with various '-filter' parameters
(Mitchell, Lanczos, Box) --- while holding the
'-quality' and '-sampling-factor' values constant ---
did not reveal significant file-size or image quality differences.
In fact, at both the '-quality 100' and '-quality 40' values
(two extremes), the fize-sizes, in bytes, for various different
filters, were exactly the same.
So in other image experiments in these web pages, I used a
constant '-filter' parameter (Mitchell) when creating JPEG files.
In this series of experiments, the best compression
of the JPEG files (from the 'original' PNG file) ---
WITHOUT encountering detectable 'mosquito noise' effects
--- was done with '-quality 85' and
sampling-factor '2x2'.
File size was 8,197 bytes ---
only 9.5% of the 85,963 bytes of the 'original' PNG file,
from 'mtpaint'.
'-quality 93' gave almost as small a JPEG file --- with
no noticeable 'mosquito noise', even after magnification
of the image.
File size was 11,101 bytes --- 12.9% of the
original 85,963 bytes.
In fact, '-quality 92' is the default 'quality' used by the
ImageMagick 'convert' command if the '-quality'
parameter is not used with an input JPEG file.
'Mosquito noise' results started getting noticeable
below about '-quality 80' --- and were very noticeable
at '-quality 60' and '-quality 40'.
My conclusion is that I could use 'convert -quality'
with quality values of about 93 or 85 or 80 and
get significant compression (about 15%, down to about 10%,
of original size) of a PNG file (from 'mtpaint') ---
that is, from a GUI image capture
and with cropping done with the 'mtpaint' image editor.
This is provided I use (or default to) a '-sampling-factor'
parameter of '2x2', rather than using '1x1' in the
'convert' command.
And even when I compare to the 'maximally crushed' PNG file
(not the big PNG file from 'mtpaint),
the JPEG file of quality 85 is about 30% smaller than that
smallest, 'lossless' PNG file.
Some details on the PNG compression results :
Maximum compression of the 'original' PNG file to
another PNG file (without losing any of the color information)
was done using the 'pngcrush' command with the
'-brute' option.
File size was 12,710 bytes ---
14.7% of the 85,963 bytes of the 'original' PNG file from 'mtpaint'.
The 'original' PNG file was compressed to another PNG,
almost as much, by using the 'convert' command with the '-quality 00'
option, where the 2 digits control compression level/type
and filter type.
The 'convert -quality 00' PNG file size was 13,766 bytes ---
16.0% of the 85,963 bytes of the 'original' PNG file from 'mtpaint'.
My conclusion is that I could use either 'convert -quality 00'
or 'pngcrush -brute' and get significant compression (about 15%
of original size) of a captured-and-cropped PNG file from
one of my GUI image captures.
Some details on the GIF compression results :
Generally I will NOT convert a PNG file, from an image capture,
to a GIF file when the image contains color 'gradients' composed
of hundreds of color shades --- because the 256 color limit of the GIF file
may result in significant loss of color information --- which
typically results in 'color bands' in an image with 'extensive' color
gradients.
However, one could almost surely use GIF files, with no loss of
color information, on gray-shaded or black-and-white images
in 'gnome-screenshot'-captured-and-'mtpaint'-cropped PNG files.
AND, one could probably get good quality GIF files from images that
contain no more than about 10 or 20 basic colors, along with no more
than a couple of hundred color shades based on that limited number
of 'basic' colors.
In fact, I did get good compression with good quality
on processing the 'original' cropped-Seamonkey-capture PNG file
to a GIF file when using the 'convert' command with the '-colors 256'
option.
Even '-colors 64' gave a good GIF image.
The image quality was just starting to suffer ('to the human eye')
around '-colors 16'.
Note that to avoid the default dithering that the ImageMagick
'convert' command does when creating GIF files, I had to
use the '+dither' option to turn off dithering.
Although, in this case, the GIF file format --- with '-colors'
around 32 --- gave the smallest file sizes (with good quality),
if I were dealing with an image with 'extensive' color gradients,
I might have to use a PNG or JPEG file to get good compression
and avoid the appearance of 'color banding' effects.
|
