Image Compression Experiments
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 detail.
This page is a link on the 'parent' web page JPEG vs. PNG vs. GIF - quality vs. file size. The 'Introduction' on that page describes some of the considerations in compressing GIF/JPEG/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 GUI was displayed on a computer 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.
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.
Here 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/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.
See quality of these images in the images section below. The file-sizes-versus-image-quality is noted there.
PNG vs. GIF vs. JPEG :
Note that we achieved the maximum loss-less compression of the PNG file to another PNG file with the '_pngcrushBRUTE.png' file --- created with the 'pngcrush' command with the '-brute' option.
We also created a PNG file about 20 times smaller than the 'original' by using the ImageMagick 'convert' command with a '-quality' compression parameter of '00'.
For the PNG '-quality' parameter of 'convert':
** 00 is recommended for images with mostly AREAS OF SOLID COLORS.
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): 0 is none, 1 is 'sub', 2 is 'up', 3 is 'average', 4 is 'Paeth', and 5 is 'adaptive'.
However, 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 a canvas area on which a shaded-image of a turbine assembly is displayed --- and that shaded image is composed of hundreds of shades of a reddish color --- 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 32 colors, the GIF file differs quite markedly in appearance from the 'original' PNG file from which it came. Many 'facets' on the turbine have disappeared. And when we go to 16 and 4 colors, most of the facets disappear.
(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 small text fonts are in an image, the 'lossy' compression of JPEG typically introduces 'mosquito noise' around the small text characters --- especially when we use a '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. These JPEG files DO show appreciable 'mosquito noise' --- which, on close examination, is seen in the '-quality 70' JPEG file --- and even more so in the '-quality 50' 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 GIF file with '-colors 256' (or perhaps 128 or 64) --- rather than use the about-twice-as-large loss-less, maximally-crushed PNG file.
I would NOT be tempted to use a JPEG file, because the high-quality '-quality 92' JPEG is larger than either of the two compressed PNG files --- and the '-quality 70' and '-quality 50' JPEG files are showing 'mosquito noise' around the text items on the GUI.
If file size was not a main concern (for example, if this were the only large image on a web page), I might choose to use one of the compressed PNG files --- because no colors have been lost from the image by the PNG-compression.
To me, it COULD be almost a coin-flip whether to use one of the compressed-PNG files or the GIF-colors-256 image file of this GUI. 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 PNG file, then I would probably choose to use the GIF file.
Below are the images. Judge for yourself.
The 'original' cropped PNG file from 'gnome-screenshot' and 'mtpaint'.
File size: 2,201,589 bytes
('mtpaint' saves to a rather large PNG file.)
JPEG from 'convert -quality 92 -sampling-factor 2x2 -filter Mitchell'
File size: 140,943 bytes
(NOTE: There is NO apparent 'mosquito noise' around the text items.)
PNG from 'convert -quality 00'
File size: 115,001 bytes
(NOTE: Nice quality and almost 20 times smaller than the 'original' PNG file.
Also about 20% smaller than the 'quality 92' JPEG file.)
PNG from the 'pngcrush' command with the '-brute' option.
File size: 101,255 bytes
(NOTE: About 20 times smaller than the 'original' PNG file.
This is the smallest PNG we can get without sacrificing some colors.)
JPEG from 'convert -quality 70 -sampling-factor 2x2 -filter Mitchell'
File size: 80,263 bytes
(NOTE: If you look closely, at this JPEG-quality level,
'mosquito noise' is apparent around the text items.
However, if you wanted a file about 20% smaller than the smallest
PNG file, above, you might tolerate this level of 'mosquito noise'
and use a JPEG file compressed to this extent.)
GIF from 'convert -colors 256 +dither' (no dithering).
File size: 65,334 bytes
(NOTE: There is no 'mosquito noise' generated in GIF files,
so none in this one. And if there were many colors lost in
generating this 256-color GIF file, it is not readily apparent
in the turbine and its facets. This image looks quite usable, and
it is about 40% smaller than the smallest PNG file, above.)
JPEG from 'convert -quality 50 -sampling-factor 2x2 -filter Mitchell'
File size: 61,907 bytes
(NOTE: Even if you could not detect the 'mosquito noise' in the quality-70 JPEG image
a couple of images above, you should be able to see considerable 'mosquito noise'
around text in this quality-50 JPEG image.)
GIF from 'convert -colors 64 +dither' (no dithering).
File size: 49,823 bytes
(NOTE: Some of the facets have disappeared in this colors-64 GIF image.)
GIF from 'convert -colors 32 +dither' (no dithering).
File size: 41,956 bytes
(NOTE: LOTS of the facets have disappeared in this colors-32 GIF image.)
GIF from 'convert -colors 16 +dither' (no dithering).
File size: 34,780 bytes
(NOTE: MOST of the facets have disappeared in this colors-16 GIF image.)
GIF from 'convert -colors 4 +dither' (no dithering).
File size: 19,959 bytes
(NOTE: Even the text areas of the GUI have significantly degraded
in this 4-color GIF image.)
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 other JPEG/PNG/GIF info :
For more information on image file quality and compression issues, for JPEG and PNG and GIF files, you can try the following Google 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 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.
Page was created 2015 Feb 03.