GIF 'Color-Compression'
Experiments

(in which the number
of colors in the GIF
'color palette' is reduced)

(investigating file-size
versus
image-quality
--- in particular,
appearance of
'color banding')


This is an example of
'color-banding' that
appeared in one of the
GIF 'color-compression'
tests below.

These are experiments in
GIF IMAGE-QUALITY
preservation
versus
COLOR-PALETTE
REDUCTION
... while recording
image-FILE-SIZE-reduction.

FE Home page > FE Screenshots page >

JPEG-vs-PNG-vs-GIF page >

This
'GIF COLOR-Compression Experiments'
page

! Note !
Text, images, file-size-data, or links may be added
or improved --- if/when I revisit this page.

Go to File Size Results, below.

Go to some Conclusions, below.

Go to Start of Test Images, below.

INTRODUCTION to the
GIF COLOR-COMPRESSION EXPERIMENTS :

This is a page of experiments in 'color-compression' when converting some sample images into GIF files.

These experiments are concerned with the quality of the 'color-compressed' images --- and also concerned with the file-size results --- as we reduce the number of colors in the GIF files.

Images are shown below, and text under each image indicates how the image file was created.

Before the images, a summary of file sizes is listed (at the bottom of this introduction) --- along with some discussion of the quality and sizes of the image files.

The summary of file sizes is followed by the images, along with comments about each image, underneath each image.

    (You can click on an image to see the image in a separate window or tab.)

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.

THIS PAGE is meant to explore GIF files in particular --- specifically, the effect of compressing an image file into a GIF file with a limited number of colors (no more than 256) --- using the '-colors' option of the ImageMagick 'convert' command.

So note that by saying we compress an image file into a GIF file, we mean that we are using the ImageMagick 'convert +dither -colors' command to do the compression.

    (We use '+dither' to assure that the image is NOT dithered --- i.e. 'speckles' of various colors are NOT added to the image.)


The motivation for these experiments :

In the years 2010 to 2014, I was making lots of web pages that included screenshots and image captures that I had done using the 'gnome-screenshot' command on PC's using a Linux operating system with a Gnome 2.28 desktop environment (Ubuntu 9.10).

The 'gnome-screenshot' command produces a PNG image file of a 'screen capture'.

I would typically use the 'mtpaint' image editor program to crop the captured image --- and typically I would, in the end, put the cropped image in a 'quality 100' JPEG file.

I used JPEG format because it is a popular format for images on web pages --- especially images that contain many colors.

I used 'quality 100' (minimal JPEG compression) because I was concerned about losing image quality if I used a lower quality level --- such as 90 or 70.

I was concerned because I had read many warnings about JPEG using a 'lossy-compression' algorithm in creating a JPEG file from any other image file format.

    Also, back around 2007, I had bad experiences with image conversion programs, on Microsoft Windows, that had the JPEG 'quality' factor hard-coded in the conversion program --- to about 'quality 70' --- which resulted in very ugly JPEG output.

I used the 'quality 100' JPEG image files in web pages of mine.

Then, in the fall of 2014, it came to my attention that if I would use 'quality 92' for the JPEG files, the images would suffer essentially NO quality loss --- for example, no apparent introduction of 'mosquito noise' around text characters in the image of a GUI.

At the same time, the file sizes of the 'quality 92' JPEG image file would typically be around half the size of the corresponding 'quality 100' JPEG image file.

Then, in further image experiments --- that I documented on the 'parent' page JPEG vs. PNG vs. GIF - image-quality vs. file-size --- I could often get even smaller file sizes --- often with no APPARENT loss in image quality --- by using a GIF file --- with a color palette of 256, or less, colors.


My typical work flow in creating
a JPEG file from a screen capture :

The steps in making a 'screen capture' image for one of my web pages were as follows.

I will take the example of wanting to display an image of a portion of a Tk GUI window.

  1. The entire GUI window is captured as a PNG file using the 'gnome-screenshot' utility --- on Ubuntu 9.10 Linux. .

  2. The 'mtpaint' image editor program is used to crop a portion out of the GUI image, and the cropped image was saved as a PNG file.

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

  3. I used the ImageMagick 'convert' command, with the '-quality 100' option, to make a 'quality 100' JPEG image file --- which I would use on a web page.

      (That 'quality 100' JPEG file was always much smaller than the PNG file that came from 'mtpaint' --- but I found in my image experiments that I could use much smaller image files --- either JPEG files with quality in the 90's or 80's --- and, in many cases, even smaller files, by using a GIF file with color palette of 256 colors --- and, in many cases, a color palette of only 32 or 16 colors --- resulting in a relatively small file size while not suffering any APPARENT loss of image quality.)

So, in the winter of 2014-2015, I found out that, by using a lower 'quality' level, I can get much smaller JPEG image files with no NOTICEABLE loss of quality, in many cases --- in particular, in the case of GUI images.

And, as I discussed on the web page JPEG vs. PNG vs. GIF - image-quality vs. file-size --- I can often, from an 'original' image capture file, get much smaller (high-quality) image files if I use GIF files --- or, at least, JPEG files with a 'quality' option in the low 90's.

In the future, for an image that I am going to put on a web page, I will generally want to try some experiments --- experiments like :

  • Use ImageMagick 'convert +dither -colors' to create GIF files with max-colors 256, 128, 64, 32, 16, 8, 4 --- in that order --- to see at what point the image quality noticeably suffers.

  • If there is image degradation right away, with a 256-color GIF, use 'convert -strip -quality' to create JPEG files of quality 100, 92, 85, and 80 say --- and see at what point the image quality noticeably suffers. (For example: at what point does 'mosquito noise' around text appear.)

  • If the smallest JPEG file I can create (without losing image quality) is not much smaller than (or is bigger than) a 'maximally-crushed' PNG file of the image --- using 'pngcrush -brute', say --- then I might use the PNG file, so that I can be assured that none of the pixels in the image have suffered a color change in making the 'maximally-crushed' PNG file.


The reasons for seeking to minimize the image size :

  1. In the case of images on MY web sites, I want my web pages to load into web browsers about as fast as they can.

    So I would like the GIF or JPEG (or PNG) images on my web pages to be nearly as small as they can be, without losing image quality, relative to the originally captured image file.

    It is especially important to have small JPEG/GIF image files on web pages where there are many JPEG/GIF files, say 10 or 20 or more.

    Such web pages could take many seconds --- maybe a minute or more --- to load into a web browser, especially on a slow internet connection.

    I would like to aim for having most of my web pages load in less than a second, on a 'broadband' connection of about 15 megabits-per-second.

  2. In the case of images on other peoples' web sites (such as the Tclers' Wiki at wiki.tcl.tk, where I have posted, and may continue to post, images), I would like to reduce the amount of space I am using on their web servers.

      To give some perspective, a single image file can take more disk space than the text of an entire, long web page.

So the 'color-compression' GIF experiments below are meant to see if I can compress various kinds of image files to a 'colors 256' (or less) GIF image file --- with no apparent loss in quality of the image --- using the ImageMagick 'convert +dither -colors' command.


GIF or JPEG files --- or PNG :

In posting images on MY web pages or on wiki.tcl.tk, I USED TO like to stay with JPEG or GIF files --- rather than PNG files, because

  1. I can generally achieve greater file size compression with GIF files (256 colors or less) or JPEG files (quality in the 90's or 80's) --- while APPARENTLY preserving the quality of the original image.

      (In those cases where I am concerned about changing the original colors of some of the pixels in the image, I could use a 'maximally-crushed' PNG file, say by using the 'pngcrush -brute' command.)

  2. GIF and JPEG are more 'mature' formats --- having been supported in many different web browsers (and other image processing programs) for at least a decade longer than the PNG format, which, by the way, has many possible 'sub-formats'.

However, since around 2008, web browsers have more consistently supported display of PNG files.

And since PNG files offer 'non-lossy' compression, I am turning more and more to using 'maximally-compressed' PNG files --- by using the 'pngcrush -brute' command on any PNG file that I will use in a web page.


The images on this page :

The 'starting' images on this page are JPEG files that were either

  • found on the Internet, or

  • they are image captures of GUI's generated by some of my Tk scripts.

The images on this page that were captured from my Tk GUI's were made as follows.

  • The computer monitor screen 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 GUI image out of the PNG file image, and the cropped image was saved as a PNG file.

  • The cropped PNG file was converted to a 'quality 100' JPEG image file by using the ImageMagick 'convert' command, using the 'quality' option.

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


The files list (and images) below :

The list of files below (and the images below) are presented in groups, corresponding to each test image file (a 'starting' JPEG).

In the file-names-and-file-sizes list below, the 'starting' JPEG file-size and file-name is presented first in each group.

The JPEG line is followed by a list of the sizes (in bytes) of the GIF files, along with their filenames, that were created --- using 'convert +dither -colors'.

In each group of test files in the list below, the filenames indicate the kind of conversion and/or compression that was done.

At the bottom of each group of files in the list below, I offer a 'Bottom-line' discussion.

You can reference the images in the bottom part of this page --- and reference the experiments of the 'parent' web page JPEG vs. PNG vs. GIF - image-quality vs. file-size --- to see the reasons for my statements.

File size results from various compression tests (on about 10 different types of image files) are listed below.

Some of the descriptive file names are quite long and may be 'folded' onto a second line.

An asterisk (*) indicates the images that were noticeably degraded from the original.



File size   Filename
  (bytes)   (with an ID-string and short description)
 --------   -----------------------------------------------------------------

   81,230   abstract_cloth_form_gray_qual100_490x490.jpg
            (quality=100 ; JPEG Type: Grayscale)

  160,585   abstract_cloth_form_gray_qual100_490x490_PALETTE256.gif

   34,978*  abstract_cloth_form_gray_qual100_490x490_PALETTE128.gif

   34,978*  abstract_cloth_form_gray_qual100_490x490_PALETTE64.gif

   18,723*  abstract_cloth_form_gray_qual100_490x490_PALETTE32.gif

   18,723*  abstract_cloth_form_gray_qual100_490x490_PALETTE16.gif

   10,364*  abstract_cloth_form_gray_qual100_490x490_PALETTE8.gif

    4,890*  abstract_cloth_form_gray_qual100_490x490_PALETTE4.gif

    2,319*  abstract_cloth_form_gray_qual100_490x490_PALETTE2.gif

            Bottom-line:
            I could use a 256-color GIF for this image (no apparent
            loss in quality), *BUT* the 256-color GIF file is
            LARGER than the 'starting' JPEG file.
            I would probably use a quality=92 JPEG file, made
            from the quality=100 'starting' JPEG file --- it would
            be about 23,000 bytes in size.

   ------------------------------------------------------------------

  115,865   abstract_color_tubes_diagonal_qual85_894x894.jpg
            (quality=85 ; JPEG Type: TrueColor)

            (As would be expected, when this quality=85 JPEG image
             is magnified, there is some 'mosquito noise'
             detectable in the crevices between the 'color tubes'.)

  287,534*  abstract_color_tubes_diagonal_qual85_894x894_PALETTE256.gif

  132,136*  abstract_color_tubes_diagonal_qual85_894x894_PALETTE64.gif

   60,895*  abstract_color_tubes_diagonal_qual85_894x894_PALETTE16.gif

   30,711*  abstract_color_tubes_diagonal_qual85_894x894_PALETTE4.gif

            Bottom-line: 
            The 256-color GIF file, and hence all the GIF files, show
            'color-banding'. I would probably use the original
            quality=85 JPEG for this image.

   ------------------------------------------------------------------

  204,967   abstract_world_orange-white-shades_qual100_662x499.jpg
            (quality=100 ; Type: TrueColor)

  168,966*  abstract_world_orange-white-shades_qual100_662x499_
            PALETTE256.gif

   83,098*  abstract_world_orange-white-shades_qual100_662x499_
            PALETTE64.gif

   38,166*  abstract_world_orange-white-shades_qual100_662x499_
            PALETTE16.gif

    9,785*  abstract_world_orange-white-shades_qual100_662x499_
            PALETTE4.gif

            Bottom-line:
            The 256-color GIF file shows a little 'color-banding'
            --- not real noticeable --- but it IS noticeable when
            compared to the 'starting' image. I would probably
            use a quality=92 JPEG made from the quality=100 
            'starting' JPEG image --- about 47,000 bytes in size.

   ------------------------------------------------------------------

  290,040   abstract_parallel_red-black-shades_qual100_801x534.jpg
            (quality=100 ; Type: TrueColor)

  299,812   abstract_parallel_red-black-shades_qual100_801x534_
            PALETTE256.gif

  159,728   abstract_parallel_red-black-shades_qual100_801x534_
            PALETTE64.gif

   66,610*  abstract_parallel_red-black-shades_qual100_801x534_
            PALETTE16.gif

   22,458*  abstract_parallel_red-black-shades_qual100_801x534_
            PALETTE4.gif

            Bottom-line:
            The 256-color GIF file shows very little quality
            difference from the 'starting' JPEG image --- and
            the 64-color GIF also looks like the 'starting' image
            --- but the difference IS noticeable when compared by
           'flipping back-and-forth' to the 'starting' image.

            Since the 256-color GIF is actually a little larger
            than the 'starting' JPEG, I would probably use a
            quality=92 JPEG made from the quality=100 'starting'
            JPEG image --- about 118,000 bytes in size.

   ------------------------------------------------------------------

   67,245   tux_reflected_on_coloredBkgd_qual100_594x450.jpg
            (quality=100 ; Type: TrueColor)

   44,857   tux_reflected_on_coloredBkgd_qual100_594x450_
            PALETTE256.gif

   17,652*  tux_reflected_on_coloredBkgd_qual100_594x450_
            PALETTE64.gif

    8,431*  tux_reflected_on_coloredBkgd_qual100_594x450_
            PALETTE16.gif

    3,842*  tux_reflected_on_coloredBkgd_qual100_594x450_
            PALETTE4.gif

            Bottom-line:
            The 256-color GIF file shows very little difference
            from the 'starting' JPEG image --- but there IS a
            little 'color banding' if you compare the 256-color
            GIF closely to the 'starting' JPEG image. I would
            probably go with a quality=92 JPEG (with NO APPARENT
            loss of image quality) made from the quality=100
            'starting' JPEG image --- with a resulting file size
            of about 21,000 bytes.

   ------------------------------------------------------------------

   40,996   yellow_wall_exif-compression-6_650x432.jpg
            ('exif:Compression: 6' ; from camera? ; Type: TrueColor)

  152,767   yellow_wall_exif-compression-6_650x432_PALETTE256.gif

   92,584*  yellow_wall_exif-compression-6_650x432_PALETTE64.gif

   55,662*  yellow_wall_exif-compression-6_650x432_PALETTE16.gif

   17,373*  yellow_wall_exif-compression-6_650x432_PALETTE4.gif

            Bottom-line:
            I could use a 256-color GIF for this image (very little
            loss in quality), *BUT* the 256-color GIF file is much
            LARGER than the 'starting' JPEG file. I would probably
            make a quality=92 JPEG file from the 'starting' JPEG file
            --- which would have a file size of about 26,000 bytes.

   ------------------------------------------------------------------

   79,203   moon_pitted_colored_qual80_640x474.jpg
            (quality=80 ; Type: TrueColor)

            (Although this is a rather low-quality 'quality 80'
             JPEG file, the image has no 'crisp' color boundaries
             within it, so there is no obvious 'mosquito noise'.)

  168,433   moon_pitted_colored_qual80_640x474_PALETTE256.gif

  108,417   moon_pitted_colored_qual80_640x474_PALETTE64.gif

   58,336*  moon_pitted_colored_qual80_640x474_PALETTE16.gif

   20,233*  moon_pitted_colored_qual80_640x474_PALETTE4.gif

            Bottom-line:
            I could use the 256-color OR the 64-color GIF for
            this image (very little difference in quality),
            *BUT* these two GIF files are much LARGER than the
            'starting' JPEG file. I would probably use the
            quality=80 'starting' JPEG.

   ------------------------------------------------------------------

  336,425   getComics_Doonesbury_2012-03-06_GUIscreenshot_qual100_
            838x287.jpg
            (quality=100 ; Type: TrueColor)

   96,234   getComics_Doonesbury_2012-03-06_GUIscreenshot_qual100_
            838x287_PALETTE256.gif

   65,048*  getComics_Doonesbury_2012-03-06_GUIscreenshot_qual100_
            838x287_PALETTE64.gif

   43,752*  getComics_Doonesbury_2012-03-06_GUIscreenshot_qual100_
            838x287_PALETTE16.gif

   24,659*  getComics_Doonesbury_2012-03-06_GUIscreenshot_qual100_
            838x287_PALETTE4.gif

            Bottom-line:
            The 256-color GIF shows very little difference from
            the 'starting' JPEG, and it is several times smaller.
            The 64-color GIF is starting to show some 'color-banding'
            in the gradiated colors in the background of the comic
            panels.
            This would probably not be noticeable to someone who
            did not have the 'starting' image with which to compare
            --- but it would bother me to use this 'degraded' image.

            I would probably use the 256-color GIF. It is smaller
            than a quality=92 JPEG that I could make from the
            quality=100 'starting' JPEG. The quality=92 JPEG
            would be about 149,000 bytes in size.

   ------------------------------------------------------------------

  188,049   rectangleEdgeShaded_ydirColorGradient_GUIscreenshot_
            qual100_700x439.jpg
            (quality=100 ; Type: TrueColor)

   38,498*  rectangleEdgeShaded_ydirColorGradient_GUIscreenshot_
            qual100_700x439_PALETTE256.gif

   25,198*  rectangleEdgeShaded_ydirColorGradient_GUIscreenshot_
            qual100_700x439_PALETTE64.gif

   16,538*  rectangleEdgeShaded_ydirColorGradient_GUIscreenshot_
            qual100_700x439_PALETTE16.gif

    9,601*  rectangleEdgeShaded_ydirColorGradient_GUIscreenshot_
            qual100_700x439_PALETTE4.gif

            Bottom-line:
            The 256-color GIF shows pronounced 'color-banding'
            in the color-gradiated 'button' in the 'canvas' of
            the Tk GUI. So none of the GIF files would be usable
            --- even though they are much smaller than the
           'starting' JPEG.

            I would probably make quality=92, 85, and 80 JPEG's
            from the quality=100 'starting' JPEG.
            If any of them shows no APPARENT loss in image quality
            AND, if it is at least 20% smaller than a
            'maximally-compressed' PNG file captured from a
            screenshot of this GUI, then I would probably use
            the JPEG. Otherwise, I would make the
            'maximally-compressed' PNG and use that.

            A quality=92 JPEG file made from this quality=100
            JPEG is about 87,000 bytes in size --- and shows
            NO APPARENT image degradation from the 'starting'
            quality=100 JPEG.

            A quality=80 JPEG file made from this quality=100
            JPEG is about 57,000 bytes in size --- and the
            'mosquito noise' around the text is hard to detect
            without magnifying the image, so there is LITTLE
            APPARENT image degradation from the 'starting'
            quality=100 JPEG.

   ------------------------------------------------------------------

   80,009   rectangleEdgeShaded_ydirColorGradient_GUIscreenshot_
            qual100_700x439_GRAYSCALE.jpg

            (quality=100 ; Type: Grayscale)

             This gray-scale JPEG was created from the above
             color JPEG file by using the ImageMagick
             'convert -colorspace Gray' command.

   62,807   rectangleEdgeShaded_ydirColorGradient_GUIscreenshot_
            qual100_700x439_GRAYSCALE_PALETTE256.gif

            Bottom-line:
            The conversion from gray-scale JPEG to a
            256-color-gray-scale GIF does not result in any loss
            in image quality.

            This is because there is no color loss --- because
            all 256 gray colors in the JPEG file --- (0,0,0) ,
            (1,1,1) , ... , (254,254,254) , (255,255,255) ---
            can be accomodated in the 256-color color-table
            ('palette') of a GIF file.

            Since the 256-color GIF file is smaller, and since
            there is no color change to ANY of the pixels in
            the image, I would use the 256-color GIF file.


See quality of these images in the 'images section' below.

CONCLUSIONS on 'color-compressed' GIF files
- versus JPEG and PNG files :

Note that in these 'to-GIF' experiments, most of the images that I used contained areas with smooth color gradients that meant that there were many 100's of colors in the image --- more than can be accomodated in the 256-colors-max color-table of a GIF file.

    (The images from the 'to-GIF' experiments are shown in the bottom part of this page.)

It is not too surprising that, in most of these experiments with color-gradient files of many hundreds of colors, I ended up concluding that using a JPEG file (of quality 92, or 85, or 80) was the best way to go --- because I could use a relatively small file while not degrading the image appearance.

One file, of these sample files, for which I would have chosen to use a GIF file was the Tk GUI with the comic-strip image.

Note that most comic strips, even ones with some color gradients in them, like this comic had, are composed of a rather limited range of colors --- in the tens or hundreds, rather than the thousands.

So it is not too surprising, in hindsight, that a GIF file could offer a faithful rendering of the original 'getComics-GUI' image, while offering a small file size.


Note that on the 'parent' page of this web page --- JPEG vs. PNG vs. GIF - image-quality vs. file-size --- the summary of experiments with about 6 different image files resulted in using GIF files for most of those images --- whereas JPEG's worked best for the images listed above.

But most of the images of the 'parent' page were of GUI's, not color-shaded images.

They were GUI's that did not have large areas with smooth color gradients.

Below are four of those images from the 'parent' page experiments, with comments.


To render this part-of-a-GUI image so that
it was indistinuishable from the 'original'
screen capture, I had to use about 32 colors
in the GIF file.

It is not very surprising that
I could use a GIF for this image,
because there are not a lot of large
patches of smooth shaded colors, and not
a wide variety of colors --- mostly
blue, green, and gray (including black)
--- and a limited number of shades of those.


To render this comic image so that it
was indistinuishable from the 'original'
screen capture, I had to use about 16 colors
in the GIF file.

It is not very surprising that
I could use a GIF for this image ---
because it is a cartoon composed of
relatively few colors --- and the only
patches of smooth shaded color were
shades of a single color --- a beige color
--- and some blue, of few shades.


To render this GUI image so that it was
indistinuishable from the 'original'
screen capture, I had to use about 16 colors
in the GIF file.

It is not very surprising that
I could use a GIF for this image ---
because it is a GUI composed of a few
basic colors --- some shades of gray, pink
and green --- and a brown title bar.


To render this GUI image so that it was
indistinuishable from the 'original'
screen capture, I had to use all 256 colors
of a GIF file.

It is not surprising that
I had to use so many colors ---
because there is a color-shaded image on
the canvas, composed of many shades of red.

In fact, if that image had other colors,
along with hundreds of shades of those
other colors, I probably would have concluded
that I would use a JPEG file, to get a
relatively small image file that was
essentially indistinguishable, in quality,
from the 'original' screen capture.

The conclusion that I gather from these several images is that I can probably use GIF images of Tk GUI's that do not contain a Tk 'canvas' with a color shaded image involving hundreds of colors.

With GIF's, I could get quite small image files yet remain true to the originally captured Tk-GUI image.

    NOTE:
    If I thought I would ever need to scale the image up or down, I would not want to use the GIF file.

    I would need to save the original JPEG or PNG file (or convert the GIF to a PNG or JPEG file and scale that file), because those two formats can accomodate the additional colors that are almost invariably needed to make a good-quality scaled up/down image.


It was rather surprising to me that the first test image (a gray-scale image in a JPEG file, below) was rendered into a LARGER file by converting to a 256-color GIF file.

Not surprisingly, the GIF was a faithful rendering of the gray-JPEG, because the 256 grays of the JPEG could all be accomodated in the 256-color-table of a GIF file.

On the other hand, the last image in the tests was also a gray-scale image, but it was rendered in a somewhat smaller file by using a 256-color GIF file.

It seems that my bottom-line conclusion has to be:

    When trying to determine which image type (GIF or JPEG or PNG) to use for a given image, it is best to do some conversion experiments.

    In many cases, a JPEG file (with quality in the 90's or 80's) will give good image quality with smallest file size.

    But in some cases, one can get an even smaller file size with a GIF file --- but the image needs to be one that does not contain large areas of gradual color gradients.


Things to avoid (with JPEG and GIF)

Note that when dealing with compressed JPEG files, we are generally trying to avoid introducing 'mosquito noise' into the image --- and when dealing with color-compressed GIF files, we are generally trying to avoid introducing 'color banding' or 'color patchiness' into the image.

If a 'maximally-compressed' PNG file of the image is not much bigger than the best compressed JPEG file that you can get, then it is probably best to go with the PNG file --- because none of the pixels in the image have had their color changed.

    (Using PNG will probably be desirable if you might do some further processing of the image --- such as scaling up or down --- at some time in the future.)


Further below are the images from conversion experiments.

Judge for yourself what you would do in each case.

(Click on these images to see the image
in a separate window or tab.)



Filename:
abstract_cloth_form_ gray_ qual100_ 490x490.jpg
The 'original' JPEG file
File size: 81,230 bytes



Filename:
abstract_cloth_form_ gray_ qual100_ 490x490_ PALETTE256.gif
256-color GIF file
File size: 160,585 bytes
About twice as big as the 'starting' JPEG file.
SURPRISE !?!



Filename:
abstract_cloth_form_ gray_ qual100_ 490x490_ PALETTE128.gif
128-color GIF file
File size: 34,978 bytes
Note the 'color bands'.



Filename:
abstract_cloth_form_ gray_ qual100_ 490x490_ PALETTE64.gif
64-color GIF file
File size: 34,978 bytes
Note the 'color bands'.



Filename:
abstract_cloth_form_ gray_ qual100_ 490x490_ PALETTE32.gif
32-color GIF file
File size: 18,723 bytes
Note the STRONG 'color bands'.



Filename:
abstract_cloth_form_ gray_ qual100_ 490x490_ PALETTE16.gif
16-colorGIF file
File size: 18,723 bytes
Note the STRONG 'color bands'.



Filename:
abstract_cloth_form_ gray_ qual100_ 490x490_ PALETTE8.gif
8-color GIF file
File size: 10,364 bytes
Note the STRONG 'color bands'.



Filename:
abstract_cloth_form_ gray_ qual100_ 490x490_ PALETTE4.gif
4-color GIF file
File size: 4,890 bytes
Note the 4 STRONG 'color bands'.



Filename:
abstract_cloth_form_ gray_ qual100_ 490x490_ PALETTE2.gif
2-colorGIF file
File size: 2,319 bytes
Note the 2 STRONG 'color bands'.


NEXT TEST IMAGE



Filename:
abstract_color_ tubes_ diagonal_ qual85_ 894x894.jpg
The 'original' JPEG file (quality=85)
(If you magnify this image,
you can see 'mosquito noise' in the crevices.)
File size: 115,865 bytes



Filename:
abstract_color_tubes_ diagonal_ qual85_ 894x894_ PALETTE256.gif
256-color GIF file
File size: 287,534 bytes
Too much 'color banding', even with 256 colors.



Filename:
abstract_color_tubes_ diagonal_ qual85_ 894x894_ PALETTE64.gif
64-color GIF file
File size: 132,136 bytes



Filename:
abstract_color_tubes_ diagonal_ qual85_ 894x894_ PALETTE16.gif
16-color GIF file
File size: 60,895 bytes



Filename:
abstract_color_tubes_ diagonal_ qual85_ 894x894_ PALETTE4.gif
4-color GIF file
File size: 30,711 bytes


NEXT TEST IMAGE



Filename:
abstract_world_ orange-white-shades_ qual100_ 662x499.jpg
The 'original' JPEG file (quality=100)
File size: 204,967 bytes



Filename:
abstract_world_ orange-white-shades_ qual100_ 662x499_ PALETTE256.gif
256-color GIF file
File size: 168,966 bytes
Too much 'color banding', even with 256 colors.



Filename:
abstract_world_ orange-white-shades_ qual100_ 662x499_ PALETTE64.gif
64-color GIF file
File size: 83,098 bytes



Filename:
abstract_world_ orange-white-shades_ qual100_ 662x499_ PALETTE16.gif
16-color GIF file
File size: 38,166 bytes



Filename:
abstract_world_ orange-white-shades_ qual100_ 662x499_ PALETTE4.gif
4-color GIF file
File size: 9,785 bytes


NEXT TEST IMAGE



Filename:
abstract_parallel_ red-black-shades_ qual100_ 801x534.jpg
The 'original' JPEG file
File size: 290,040 bytes



Filename:
abstract_parallel_ red-black-shades_ qual100_ 801x534_ PALETTE256.gif
256-color GIF file
File size: 299,812 bytes
There is some 'patchiness' on the left
of the red area, even with 256 colors.
It is definitely visible in the next image.



Filename:
abstract_parallel_ red-black-shades_ qual100_ 801x534_ PALETTE64.gif
64-color GIF file
File size: 159,728 bytes



Filename:
abstract_parallel_ red-black-shades_ qual100_ 801x534_ PALETTE16.gif
16-color GIF file
File size: 66,610 bytes
There is definite quality degradation
in the gray-to-black areas.



Filename:
abstract_parallel_ red-black-shades_ qual100_ 801x534_ PALETTE4.gif
4-color GIF file
File size: 22,458 bytes


NEXT TEST IMAGE



Filename:
tux_reflected_on_ coloredBkgd_ qual100_ 594x450.jpg
The 'original' JPEG file
File size: 67,245 bytes



Filename:
tux_reflected_on_ coloredBkgd_ qual100_ 594x450_ PALETTE256.gif
256-color GIF file
File size: 44,857 bytes
There is a hint of 'color banding'
across the blue area,
even with 256 colors.



Filename:
tux_reflected_on_ coloredBkgd_ qual100_ 594x450_ PALETTE64.gif
64-color GIF file
File size: 17,652 bytes



Filename:
tux_reflected_on_ coloredBkgd_ qual100_ 594x450_ PALETTE16.gif
16-color GIF file
File size: 8,431 bytes



Filename:
tux_reflected_on_ coloredBkgd_ qual100_ 594x450_ PALETTE4.gif
4-color GIF file
File size: 3,842 bytes


NEXT TEST IMAGE



Filename:
yellow_wall_ exif-compression-6_ 650x432.jpg
The 'original' JPEG file (quality = ? ; from camera ? )
File size: 40,996 bytes



Filename:
yellow_wall_ exif-compression-6_ 650x432_ PALETTE256.gif
256-color GIF file
File size: 152,767 bytes
There is a hint of 'color banding' and
'patchiness' of yellow on the
mid-left, even with 256 colors.

This image degradation is more visible
in the next image.



Filename:
yellow_wall_ exif-compression-6_ 650x432_ PALETTE64.gif
64-color GIF file
File size: 92,584 bytes
This GIF file is more than twice
the size of the 'starting' JPEG.



Filename:
yellow_wall_ exif-compression-6_ 650x432_ PALETTE16.gif
16-color GIF file
File size: 55,662 bytes



Filename:
yellow_wall_ exif-compression-6_ 650x432_ PALETTE4.gif
4-color GIF file
File size: 17,373 bytes


NEXT TEST IMAGE



Filename:
moon_pitted_colored_ qual80_ 640x474.jpg
The 'original' JPEG file (quality = 80)
File size: 79,203 bytes



Filename:
moon_pitted_colored_ qual80_ 640x474_ PALETTE256.gif
256-color GIF file
File size: 168,433 bytes
This 256-color-GIF is more than
twice the size of the 'starting' JPEG.



Filename:
moon_pitted_colored_ qual80_ 640x474_ PALETTE64.gif
64-color GIF file
File size: 108,417 bytes



Filename:
moon_pitted_colored_ qual80_ 640x474_ PALETTE16.gif
16-color GIF file
File size: 58,336 bytes



Filename:
moon_pitted_colored_ qual80_ 640x474_ PALETTE4.gif
4-color GIF file
File size: 20,233 bytes


NEXT TEST IMAGE



Filename:
getComics_Doonesbury_ 2012-03-06_ GUIscreenshot_ qual100_ 838x287.jpg
The 'original' JPEG file (quality 100)
File size: 336,425 bytes



Filename:
getComics_Doonesbury_ 2012-03-06_ GUIscreenshot_ qual100_ 838x287_ PALETTE256.gif
256-color GIF file
File size: 96,234 bytes
This 256-color-GIF is less than
one-third the size of the 'starting' JPEG.
And the quality is quite good ---
no readily apparent degradation.



Filename:
getComics_Doonesbury_ 2012-03-06_ GUIscreenshot_ qual100_ 838x287_ PALETTE64.gif
64-color GIF file
File size: 65,048 bytes
There is some 'color-banding' in the
shaded background of the 3rd frame.



Filename:
getComics_Doonesbury_ 2012-03-06_ GUIscreenshot_ qual100_ 838x287_ PALETTE16.gif
16-color GIF file
File size: 43,752 bytes



Filename:
getComics_Doonesbury_ 2012-03-06_ GUIscreenshot_ qual100_ 838x287_ PALETTE4.gif
4-color GIF file
File size: 24,659 bytes


NEXT TEST IMAGE



Filename:
rectangleEdgeShaded_ ydirColorGradient_ GUIscreenshot_ qual100_ 700x439.jpg
The 'original' JPEG file (quality 100)
File size: 188,049 bytes



Filename:
rectangleEdgeShaded_ ydirColorGradient_ GUIscreenshot_ qual100_ 700x439_ PALETTE256.gif
256-color GIF file
File size: 38,498 bytes
There is obvious 'color banding',
even with 256 colors.



Filename:
rectangleEdgeShaded_ ydirColorGradient_ GUIscreenshot_ qual100_ 700x439_ PALETTE64.gif
64-color GIF file
File size: 25,198 bytes



Filename:
rectangleEdgeShaded_ ydirColorGradient_ GUIscreenshot_ qual100_ 700x439_ PALETTE16.gif
16-color GIF file
File size: 16,538 bytes



Filename:
rectangleEdgeShaded_ ydirColorGradient_ GUIscreenshot_ qual100_ 700x439_ PALETTE4.gif
4-color GIF file
File size: 9,601 bytes


NEXT TEST IMAGE



Filename:
rectangleEdgeShaded_ ydirColorGradient_ GUIscreenshot_ qual100_ 700x439_ GRAYSCALE.jpg
Gray-scale JPEG file
File size: 80,009 bytes
This gray-scale JPEG was created
from the above color JPEG file
by using the ImageMagick
'convert -colorspace Gray' command.



Filename:
rectangleEdgeShaded_ ydirColorGradient_ GUIscreenshot_ qual100_ 700x439_ GRAYSCALE_ PALETTE256.gif
256-color GIF file
File size: 62,807 bytes
NOTE:
The conversion from gray-scale JPEG
to 256-color-gray-scale GIF does not
result in any loss in image quality.

This is because there is NO
color change to ANY pixel ---
because all 256 gray colors in
the JPEG file --- (0,0,0) , (1,1,1) ,
... , (254,254,254) , (255,255,255) ---
can be accomodated in the 256-color
color-table ('palette') of a GIF file.

Unlike with the first gray-scale
JPEG-to-GIF test above, this
good-quality 256-gray-color-GIF is
smaller than the 'starting' JPEG.

MORE GIF-COLOR-COMPRESSION IMAGE EXPERIMENTS :

Some more GIF-color-compression experiments may eventually be added to this page --- if questions arise that are not answered by the image experiments above.

'External' WEB LINKS to
other GIF-COLOR-COMPRESSION info :

For more information on image file quality and compression issues, when compressing GIF files (by reducing the 'color palette'), 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
GIF COLOR-Compression Experiments - on a variety of color and gray-scale images.

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 history:

Page was created 2015 Mar 08.

Page was changed 2015 Mar 11.

Page was changed 2018 Aug 17.
(Added css and javascript to try to handle text-size for smartphones, esp. in portrait orientation.)

Page was changed 2019 Jul 11.
(Specified image widths in percents to size the images according to width of the browser window. Added some web links.)