Image Compression Experiments
on the image of a
|
This is a GUI image used in the PNG, JPEG, GIF experiments below --- experiments in image-file-size-COMPRESSION versus image-QUALITY-preservation. |
! Note !
Text, images, file-size-data, or links may be added
or improved --- if/when I revisit this page.
|
INTRODUCTION to the IMAGE EXPERIMENTS : This is a page of experiments in image compression-versus-quality. Images are shown, and text under each image explains how the image was processed. Before the images, a summary of file sizes is listed, at the bottom of this introduction --- along with some discussion of how one may be able to get relatively small GIF or JPEG or PNG image files while preserving (for the most part) the quality of the original, captured image. The summary of file sizes is followed by the images, along with some information about each image, underneath each image. If you want to examine the images --- for example, by magnifying them --- you can 'right-click' on each image to do a 'Save As ...' of the image file to your local computer. Then you can use image-viewing software on your computer to examine any of these images in great detail. This page is a link on the 'parent' web page JPEG vs. PNG vs. GIF - image-quality vs. file-size. The 'Introduction' on that page describes some of the considerations in compressing GIF, JPEG, and PNG files while preserving the quality of the original image (in terms of what the eye can see, without magnifying the image). See 'The bottom line' section of that page. It contains a summary of GIF-JPEG-PNG compression-versus-quality guidelines that were deduced from the image compression experiments in these web pages. The making of the images on this page : The images on this page were made from an 'original' image in a PNG file. That 'original' image-file was created by doing an 'entire-screen' capture (to a PNG file) when the 'wheeeMorph' GUI was displayed on the screen. The capture was done with the 'gnome-screenshot' utility. I then used the 'mtpaint' image-editor program to read the PNG file and crop the GUI image from the image of the entire screen. I saved the cropped image to a PNG file, from the 'mtpaint' program --- which creates rather large PNG files that can be compressed using a utility command like pngcrush. So the 'original' PNG file was made using the 'gnome-screenshot' and 'mtpaint' programs. Other, compressed image files (PNG, GIF, and JPEG) were made from this 'original' PNG file by using either
In a little more detail, the steps in making these images were as follows.
Below is a list of the sizes (in bytes) and names of the image files shown below --- sorted by size, largest files first. The filenames indicate the kind of conversion and/or compression that was done. |
|
File size results from various compression tests are listed below --- in file size order --- largest to smallest. The descriptive file names are quite long and have been 'folded' onto a second line. |
The 'original' PNG screenshot file:
('mtpaint' creates large PNG files)
2,201,589 wheeeMorph_Cheney_drawing-photo_deformed-grids_
gnome-screenshot_fromMTpaintCrop_1024x715.png
to-compressed-PNG via ImageMagick 'convert' PNG-compression:
503,095 wheeeMorph_Cheney_drawing-photo_deformed-grids_
gnome-screenshot_fromMTpaintCrop_1024x715_CompressType00.png
to-compressed-PNG via 'pngcrush' compression:
376,393 wheeeMorph_Cheney_drawing-photo_deformed-grids_
gnome-screenshot_fromMTpaintCrop_1024x715_pngcrushBRUTE.png
to-JPEG - quality-92 (via ImageMagick 'convert'):
277,349 wheeeMorph_Cheney_drawing-photo_deformed-grids_
gnome-screenshot_fromMTpaintCrop_1024x715_Quality92_
SampFact2x2_FilterMitchell_Stripped.jpg
to-GIF up-to-256-colors (via ImageMagick 'convert'):
219,802 wheeeMorph_Cheney_drawing-photo_deformed-grids_
gnome-screenshot_fromMTpaintCrop_1024x715_PALETTE256.gif
to-JPEG - quality-80:
185,566 wheeeMorph_Cheney_drawing-photo_deformed-grids_
gnome-screenshot_fromMTpaintCrop_1024x715_Quality80_
SampFact2x2_FilterMitchell_Stripped.jpg
to-GIF up-to-128-colors:
176,983 wheeeMorph_Cheney_drawing-photo_deformed-grids_
gnome-screenshot_fromMTpaintCrop_1024x715_PALETTE128.gif
to-JPEG - quality-70:
152,433 wheeeMorph_Cheney_drawing-photo_deformed-grids_
gnome-screenshot_fromMTpaintCrop_1024x715_Quality70_
SampFact2x2_FilterMitchell_Stripped.jpg
to-GIF up-to-64-colors:
147,541 wheeeMorph_Cheney_drawing-photo_deformed-grids_
gnome-screenshot_fromMTpaintCrop_1024x715_PALETTE64.gif
to-GIF up-to-16-colors:
92,879 wheeeMorph_Cheney_drawing-photo_deformed-grids_
gnome-screenshot_fromMTpaintCrop_1024x715_PALETTE16.gif
|
See quality of these images in the 'images section' below. The file-sizes versus image-quality is discussed there. |
|
PNG vs. GIF vs. JPEG : Note that we achieved the maximum LOSS-LESS compression of the PNG file (to another PNG file) in the '_pngcrushBRUTE.png' file --- created with the 'pngcrush' command with the '-brute' option. We also created a PNG file about one-fourth the size of the 'original' by using the ImageMagick 'convert' command with a '-quality' compression parameter of '00'. For the PNG '-quality' parameter of 'convert':
The first digit (tens) is the zlib compression level, 1-9. However if a setting of '0' is used you will get Huffman compression rather than 'zlib' compression, which is often better! The second digit is the PNG data encoding filtering type (before the data is compressed):
The filtering type did not seem to affect file-size significantly, so filter-type zero (none) was used. We can get still smaller files, than these PNG files, by allowing some 'lossiness' --- by going to GIF files (with a max of 256 colors) or by using the 'lossy' compression inherent in creating JPEG files. On GIF : Since this GUI image contains 2 canvas areas on which color-shaded images may be displayed --- and those two images may be composed of hundreds of shades of various colors --- we can expect that we are going to lose some image quality if we convert the 'original' PNG file to a GIF file ---- even if we choose to specify the maximum of 256 colors. In fact, it turned out that for this GUI image, when we go down to about 64 colors, the GIF file differs quite markedly in appearance from the 'original' PNG file from which it came. Some 'color banding' is apparent on the photo-portrait image. And when we go to a 16-color GIF, the color banding gets clearly worse. (We could try converting the 'original' PNG file to PNG files with a restricted number of colors --- such as 256 or 16 --- but if we are going to do that, I would rather use GIF --- since it has been supported by web browsers for about 10 more years than PNG --- and there may be some cases of software not reading certain types of PNG files.) On JPEG : Note that when text fonts (in a quite contrasting color to their background) are in an image, the 'lossy' compression of JPEG typically introduces 'mosquito noise' around the text characters --- especially when we use a 'convert' '-quality' value lower than the range of 100 to 92. In this GUI image, there are many 'fine', small text characters --- so we DO have to be concerned about introducing 'mosquito noise' when converting the 'original' PNG file to a JPEG file of 'quality' less than 92. The less-than-92-quality JPEG files below DO show some 'mosquito noise' --- which, on close examination, is seen in the '-quality 80' JPEG file --- and even more so in the '-quality 70' JPEG file. On choosing a file-type : For this particular image, IF file size was my main concern (for example, if I were posting the image on a web page along with a lot of other images), I would be tempted to use a JPEG file of 'quality' 70 (or, better yet, 80) rather than use the loss-less, maximally-crushed PNG file. Those JPEG's would be about half the size of the loss-less, maximally crushed PNG file. Alternatively, I would use a GIF file with at least 64-colors --- because its size and quality compare favorably with the JPEG's that were created with '-quality' of about 70 to 80. To me, it would be almost a coin-flip whether to use the JPEG-quality-80 or the GIF-colors-128 image file of this GUI image. If it proved to be the case that a GIF file would load into a web page faster (or with less CPU processing) than the JPEG file, then I would probably choose the GIF file. Below are the images. Judge for yourself. |
(Click on these images to see the image
in a separate window or tab.)
The 'original' cropped PNG file
from 'gnome-screenshot' and 'mtpaint'.
File size: 2,201,589 bytes
(The 'mtpaint' image-editor saves to
a rather large PNG file.)
PNG from 'convert -quality 00'
File size: 503,095 bytes
NOTE:
Nice quality of this losslessly compressed
PNG file from the original PNG from 'mtpaint'
--- and about 4 times smaller than the
'original' PNG file.
PNG from the
'pngcrush' command with the '-brute' option.
File size: 376,393 bytes
NOTE:
Nice quality of this maximally-compressed
PNG file and about 6 times smaller than
the 'original' PNG file from 'mtpaint'.
This is essentially the smallest PNG that
we can get without sacrificing some colors.
JPEG from
'convert -quality 92 -sampling-factor 2x2 -filter Mitchell'
File size: 277,349 bytes
NOTE:
There is NO apparent 'mosquito noise' around
the text items. This image is quite usable, and
is about 25 percent smaller than the
maximally crushed PNG file.
GIF from
'convert -colors 256 +dither' (no dithering).
File size: 219,802 bytes
NOTE:
There is no 'mosquito noise' generated in
non-dithered GIF files, so none in this one.
If there were many colors lost in generating
this 256-color GIF file, it is not readily
apparent in the photo-portrait on the
right-side of the GUI. This image looks
quite usable, and it is about 40 percent
smaller than the smallest PNG file, above.
JPEG from
'convert -quality 80 -sampling-factor 2x2 -filter Mitchell'
File size: 185,566 bytes
NOTE:
If you look closely at this 'quality-80' JPEG image,
there is hardly any 'mosquito noise' detectable
around the text items. If you wanted a file about
50 percent smaller than the smallest PNG file, above
--- and you did not want to use a GIF file ---
you might tolerate this miniscule level of 'mosquito
noise' and use a JPEG file compressed to this extent.
GIF from
'convert -colors 128 +dither' (no dithering).
File size: 176,983 bytes
NOTE:
There is no 'mosquito noise' generated in non-dithered
GIF files, so none in this one. There may be quite a few
colors lost in generating this 128-color GIF file.
There appears to be some degradation in the
photo-portrait on the right-side of the GUI ---
for example, some 'color banding' on the cheeks. However,
this image looks quite usable, and it is less than
half the size of the smallest PNG file, above.
JPEG from
'convert -quality 70 -sampling-factor 2x2 -filter Mitchell'
File size: 152,433 bytes
NOTE:
If you look closely at this 'quality-70' JPEG image, a
little bit of 'mosquito noise' is detectable around
some of the text items. However, if you wanted a file
less than half the size of the smallest PNG file, above
--- and you did not want to use a GIF file ---
you might tolerate this level of 'mosquito noise' and
use a JPEG file compressed to this extent.
GIF from
'convert -colors 64 +dither' (no dithering).
File size: 147,541 bytes
NOTE:
The text is quite clear, BUT 'color-banding' on the
cheeks is quite evident --- in this colors-64 GIF image.
I would NOT want to use this image.
GIF from 'convert -colors 16 +dither' (no dithering).
File size: 92,879 bytes
NOTE:
Although the text is still clear, even more severe
'color-banding' appears in this colors-16 GIF image.
Unusable.
|
MORE IMAGE EXPERIMENTS : Some other PNG-JPEG-GIF compression-versus-quality experiments (using different image types) are available from the 'parent' page of this page --- the JPEG vs. PNG vs. GIF - image-quality vs. file-size page. |
|
'External' WEB LINKS to For more information on image file quality and compression issues, for JPEG and PNG and GIF files, you can try the following WEB SEARCHES on the indicated keywords. You may wish to change or add keywords to these queries in order to hone in on answers to your particular questions. |
|
Bottom of this page of
To return to a previously visited web page, click on the
Back button of your web browser a sufficient number of times.
OR, use the History-list option of your web browser.
< Go to Top of Page, above. >
Page history:
Page was created 2015 Feb 03.
|