Image Compression Experiments


on an image cropped from the upper-left
corner of the Seamonkey web browser GUI


(JPEG, PNG, GIF files - compression
of file-size versus preserving image-quality)


This is the image used in the PNG, JPEG, and
GIF experiments below --- experiments in image-
COMPRESSION versus image-QUALITY-preservation.

FE Home page > JPEG-vs-PNG-vs-GIF page >
This 'Compression-versus-Quality Experiments (on a Seamonkey Top-Left-GUI-image)' page

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 can get relatively small JPEG or PNG or GIF 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. Click on each image to see a magnification of the image.

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 JPEG/PNG/GIF 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 JPEG/PNG/GIF compression-versus-quality guidelines that were deduced from the image compression experiments in these web pages.


The images on this page :

The images on this page were made from an 'original' image in a PNG file. That image was cropped from the upper-left portion of a screen capture of the Seamonkey web browser GUI.

The steps in making these images were as follows.

  • The entire Seamonkey web browser window was captured as a PNG file using the 'gnome-screenshot' utility --- on Ubuntu 9.10 Linux. .

  • The 'mtpaint' image editor program was used to crop the upper-left portion out of the GUI image, and the cropped image was saved as a PNG file. That PNG file is the first of the images below.

      (The 'mtpaint' image editor tends to make rather large PNG files --- larger than the PNG file that was read in --- even after some cropping.)

  • Various PNG and JPEG and GIF files are shown below --- in file-size order, largest first. Most of the compressed images were made with the ImageMagick 'convert' command. One image was made with 'pngcrush'.

  • All but one of the JPEG files shown below were made from the 'original' PNG file at the top of these images, using the ImageMagick 'convert' command, with the '-quality' and '-sampling factor' and '-filter' options.

    The '-strip' option of the 'convert' command was used to assure that the JPEG file would be stripped of text data such as EXIF text data.

    Experiments on this Seamonkey GUI image capture have indicated that smaller JPEG files are yielded when the '-sampling-factor 2x2' option is used --- rather than '1x1' or '2x1'.

    Some of these JPEG-making experiments also indicated that the choice of '-filter' may not have a great influence on file-size --- at least not as much influence as '-quality' and '-colors' options.

    One JPEG file was made from the 'original' PNG file by using the the 'SaveAs' option of the 'mtpaint' image editor --- with 'quality=100'.

  • Some compressed PNG files were made from the 'original' PNG file at the top of these images, using either the 'pngcrush' command with the '-brute' option --- OR the 'convert' command with the '-quality' option.

  • GIF files were made from the 'original' PNG file at the top of these images, using the 'convert' command with the '-colors' option --- and with '+dither' to turn OFF dithering. A range of '-colors' values were used --- from 256 to 4.

  • File-size results are summarized just below. See the images further below to examine the image quality.

Here is a list of the sizes (in bytes) and names of the following image files --- sorted by size, largest files first. The filenames indicate the kind of conversion/compression that was done.

   85,963     seamonkeyGUI_upperLeft_screenshot_246x115.png
             (The 'original' cropped PNG file.)

   33,052     seamonkeyGUI_upperLeft_screenshot_246x115_Quality100_SampFact1x1_FilterMitchell_Stripped.jpg

   24,436     seamonkeyGUI_upperLeft_screenshot_246x115_mtpaintQuality100.jpg

   20,292     seamonkeyGUI_upperLeft_screenshot_246x115_Quality100_SampFact2x2_FilterLanczos_Stripped.jpg
   20,292     seamonkeyGUI_upperLeft_screenshot_246x115_Quality100_SampFact2x2_FilterBox_Stripped.jpg
   20,292     seamonkeyGUI_upperLeft_screenshot_246x115_Quality100_SampFact2x2_FilterMitchell_Stripped.jpg
   15,793     seamonkeyGUI_upperLeft_screenshot_246x115_Quality93_SampFact1x1_FilterMitchell_Stripped.jpg

   13,776     seamonkeyGUI_upperLeft_screenshot_246x115_CompressType00.png

   13,389     seamonkeyGUI_upperLeft_screenshot_246x115_Quality90_SampFact1x1_FilterMitchell_Stripped.jpg

   12,710     seamonkeyGUI_upperLeft_screenshot_246x115_pngcrushBRUTE.png

   11,101     seamonkeyGUI_upperLeft_screenshot_246x115_Quality93_SampFact2x2_FilterMitchell_Stripped.jpg
   10,903     seamonkeyGUI_upperLeft_screenshot_246x115_Quality85_SampFact1x1_FilterMitchell_Stripped.jpg
    9,272     seamonkeyGUI_upperLeft_screenshot_246x115_Quality80_SampFact1x1_FilterMitchell_Stripped.jpg
    8,179     seamonkeyGUI_upperLeft_screenshot_246x115_Quality85_SampFact2x2_FilterMitchell_Stripped.jpg

    7,338     seamonkeyGUI_upperLeft_screenshot_246x115_Quality70_SampFact1x1_FilterMitchell_Stripped.jpg

    7,188     seamonkeyGUI_upperLeft_screenshot_246x115_PALETTE256.gif

    6,134     seamonkeyGUI_upperLeft_screenshot_246x115_Quality60_SampFact1x1_FilterMitchell_Stripped.jpg

    4,823     seamonkeyGUI_upperLeft_screenshot_246x115_PALETTE64.gif

    4,673     seamonkeyGUI_upperLeft_screenshot_246x115_Quality40_SampFact1x1_FilterMitchell_Stripped.jpg

    3,498     seamonkeyGUI_upperLeft_screenshot_246x115_PALETTE16.gif
    2,136     seamonkeyGUI_upperLeft_screenshot_246x115_PALETTE4.gif

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. That '_pngcrushBRUTE.png' file was about 7 times smaller than the 'original' PNG file.

We also created a PNG file about 6 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.
    ** 05 is recommended for images like NATURAL LANDSCAPES.
    ** 00 and 90 seem to give small file sizes with good quality.
    
       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.

The size of the 'brute-crushed' PNG file corresponded to the size of JPEG files of 'quality' about 93 to 85. Those JPEG files do NOT show appreciable 'mosquito noise'.

For this particular image, if I were posting the image on a web page or including the image in an email --- and IF file size was my main concern --- I would be tempted to use a JPEG file of 'quality' 85 (or even 80) rather than use the loss-less, maximally-crushed PNG file. The JPEG's would be about 20 to 40 percent smaller than the loss-less, maximally crushed PNG file.

But we can get even smaller files (of good quality) by using the GIF format.

On GIF :

Since this GUI image is composed primarily of several basic colors (mostly black and white and gray and green and blue), we can expect to preserve most of the original image if we convert the 'original' PNG file to a GIF file of less than 256 colors. In fact, it turned out that for this image, we could even go down to 16 colors and still get a GIF file that was quite close in appearance to the 'original' PNG file from which it came.

(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.

Significant 'mosquito noise' was generated in the JPEG files of 'quality' 70, 60, and 40 --- which were created from the 'original' PNG file.

The 256-color GIF file, also created from the 'original' PNG file, has no such 'mosquito noise' and is comparable in size to JPEG files of 'quality' about 70 to 65. The 64-color GIF file was definitely of better quality than the quality 60 and 40 JPEG files, which DO show detectable 'mosquito noise' --- and the 64-color GIF file was less than half the size of the maximally-crushed PNG 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 16-color (or 32-color) GIF file rather than use the loss-less, maximally-crushed PNG file.

For this particular image, the 256-color GIF file was about 60 percent of the size of the 'brute-crushed' PNG file --- and the 16-color GIF file is about 30 percent of the size of the loss-less, maximally crushed PNG file.

For this particular image, if I were posting the image on a web page, I would be tempted to use the (un-dithered) 16-color GIF file rather than a JPEG or a loss-less, maximally-crushed PNG file --- even though there are undoubtedly some 'lost' colors in the GIF file. I would choose a 16- or 32-color GIF file because there is no apparent loss of image quality for this GUI image, in spite of there being a limit of 16 or 32 colors available in the GIF file.


Further below are the images. Judge for yourself.

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: 8,197 bytes --- only 9.5% of the 85,963 bytes of the 'original' PNG file.

'-quality 93' gave almost as small a JPEG file --- with no noticeable 'mosquito noise', even after magnification of the image. File size: 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 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'.

And even when I compare to the 'maximally crushed' PNG file, the JPEG file of quality 85 is about 30% smaller the 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: 12,710 bytes --- 14.7% of the 85,963 bytes of the 'original' PNG file.

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 '-quality 00' file size was 13,766 bytes --- 16.0% of the 85,963 bytes of the 'original' PNG file.

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 on gray-shaded or black-and-white images captured-and-cropped PNG files with no loss of color information.

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. (Those 'speckles' in the GIF image ruin the quality.)

Although, in this case, the 256-max-colors 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.

(Click on these images to see a 300-percent magnified image.)



The 'original' cropped PNG file from 'gnome-screenshot' and 'mtpaint'.
File size: 85,963 bytes
('mtpaint' saves to a rather large PNG file.)



JPEG from 'convert -quality 100 -sampling-factor 1x1 -filter Mitchell'
File size: 33,052 bytes
(NOTE: There is NO apparent 'mosquito noise' around the text items.
This image is quite usable, BUT it is more than twice the size of
a quality-93 JPEG file, below, which also shows no 'mosquito noise'.)



JPEG from 'mtpaint' 'Save As' with 'quality=100'.
File size: 24,436 bytes
(NOTE: There is NO apparent 'mosquito noise' around the text items.
This image is quite usable, BUT it is more than twice the size of
a quality-93 JPEG file, below, which also shows no 'mosquito noise'.)



JPEG from 'convert -quality 100 -sampling-factor 2x2 -filter Lanczos'
File size: 20,292 bytes
(NOTE: This quality-100 JPEG file, and the following two JPEG's of the same size,
indicate that by using '2x2' for the sampling-factor, rather than '1x1', we can
get better JPEG compression --- at least, at the quality-100 level.)



JPEG from 'convert -quality 100 -sampling-factor 2x2 -filter Box'
File size: 20,292 bytes



JPEG from 'convert -quality 100 -sampling-factor 2x2 -filter Mitchell'
File size: 20,292
(NOTE: No difference in file size with the 3 different filters --- Lanczos,
Box, and Mitchell --- above, BUT using '2x2' for the sampling-factor,
rather than '1x1', resulted in a smaller file size.)



JPEG from 'convert -quality 93 -sampling-factor 1x1 -filter Mitchell'
File size: 15,793 bytes
(NOTE: With this 'quality-93' JPEG file, there is NO apparent 'mosquito noise'
around the text items --- and it is at least 25 percent smaller than the 'quality-100'
JPEG files above.)



PNG from 'convert -quality 00'
File size: 13,776 bytes
(NOTE: This 'convert-quality-00' PNG file has nice quality and
is about 6 times smaller than the 'original' PNG file.)



JPEG from 'convert -quality 90 -sampling-factor 1x1 -filter Mitchell'
File size: 13,389 bytes
(NOTE: With this 'quality-90' JPEG file, there is NO READILY APPARENT 'mosquito noise'
around the text items --- and it is about 25 percent smaller than the 'quality-93'
JPEG file above.)



PNG from 'pngcrush -brute'
File size: 12,710 bytes
(NOTE: Nice quality and about 7 times smaller than the 'original' PNG file.
This is the smallest PNG we can get without sacrificing some colors.)



JPEG from 'convert -quality 93 -sampling-factor 2x2 -filter Mitchell'
File size: 11,101 bytes
(NOTE: Using '2x2' --- rather than '1x1' --- in making this 'quality-93' JPEG file
resulted in a file about 25 percent smaller than the 'quality-93' JPEG file several images above.)



JPEG from 'convert -quality 85 -sampling-factor 1x1 -filter Mitchell'
File size: 10,903 bytes
(NOTE: Although I do not see 'mosquito noise' in this 'quality-85' JPEG image,
I can discern some noise in the 3-times magnified image.)



JPEG from 'convert -quality 80 -sampling-factor 1x1 -filter Mitchell'
File size: 9,272 bytes
(NOTE: Although I do not see 'mosquito noise' in this 'quality-80' JPEG image,
I can see noise quite clearly in the 3-times magnified image.)



JPEG from 'convert -quality 85 -sampling-factor 2x2 -filter Mitchell'
File size: 8,179 bytes
(NOTE: Although I do not see 'mosquito noise' in this 'quality-85' and '2x2' JPEG image,
I can see discern some noise in the 3-times magnified image.)



JPEG from 'convert -quality 70 -sampling-factor 1x1 -filter Mitchell'
File size: 7,338 bytes
(NOTE: There is definite 'mosquito noise' in this 'quality-70' JPEG image.
It is quite clear in the 3-times magnified image.)



GIF from 'convert -colors 256 +dither'
File size: 7,188 bytes
(NOTE: There is no 'mosquito noise' generated in GIF files,
so none in this one. And if there were some colors lost in
generating this 256-color GIF file, it is not readily apparent
anywhere on this GUI image. This image looks quite usable, and
it is about 25 percent smaller than the smallest PNG file, above.)



JPEG from 'convert -quality 60 -sampling-factor 1x1 -filter Mitchell'
File size: 6,134 bytes
(NOTE: There is definite 'mosquito noise' in this 'quality-60' JPEG image.
It is quite clear in the 3-times magnified image.)



GIF from 'convert -colors 64 +dither'
File size: 4,823 bytes
(NOTE: Nice quality in this 64-color GIF file. It is quite usable.
No apparent visual 'artifacts' --- even in the 3-times magnified image.
This file is about two-thirds the size of the 256-color GIF file.)



JPEG from 'convert -quality 40 -sampling-factor 1x1 -filter Mitchell'
File size: 4,673 bytes
(NOTE: There is definite 'mosquito noise' in this 'quality-40' JPEG image.
It is quite clear in the 3-times magnified image.)



GIF from 'convert -colors 16 +dither'
File size: 3,498 bytes
(NOTE: Pretty good quality in this 16-color GIF file. But some
visual 'artifacts' are apparent in the 3-times magnified image.
I would prefer to use a GIF file with more colors, say a 32-color GIF.)



GIF from 'convert -colors 4 +dither'
File size: 2,136 bytes
(NOTE: Poor quality in this 4-color GIF file. Many 'artifacts'
are apparent in the 3-times magnified image. Not usable.)

MORE IMAGE EXPERIMENTS :

Some more compression-versus-quality experiments (on different images) may eventually be 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 the page of Image Compression Experiments - upper-left of Seamonkey web browser GUI.

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.
OR ...

< Go to Top of Page, above. >
< Go to FE Home page >

Page created 2014 Dec 16. Page changed 2015 Feb 07.