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')


Several different image types are used below.



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

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 '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 would be captured as a PNG file using the 'gnome-screenshot' utility --- on Ubuntu 9.10 Linux. .

  2. The 'mtpaint' image editor program was 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 90's or 80's.

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

  • Use '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.

  • And, 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.

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


Why I like to use GIF or JPEG files :

In posting images on MY web pages or on wiki.tcl.tk, I would 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'.


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 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/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.)

So it is not too surprising that, in most of these experiments, 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. Here 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. (NOTE: This image was reduced in size from the
original GUI size, to be similar in size to the other 3 images above.)

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 tkGUI 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, 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.

    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. (This might be desirable if you might do some further processing of the image at some time in the future.)


Further below are the images. Judge for yourself what you would do in each case.

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



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.



Filename: abstract_cloth_form_gray_qual100_490x490_PALETTE128.gif
128-color GIF file
File size: 34,978 bytes



Filename: abstract_cloth_form_gray_qual100_490x490_PALETTE64.gif
64-color GIF file
File size: 34,978 bytes



Filename: abstract_cloth_form_gray_qual100_490x490_PALETTE32.gif
32-color GIF file
File size: 18,723 bytes



Filename: abstract_cloth_form_gray_qual100_490x490_PALETTE16.gif
16-colorGIF file
File size: 18,723 bytes



Filename: abstract_cloth_form_gray_qual100_490x490_PALETTE8.gif
8-color GIF file
File size: 10,364 bytes



Filename: abstract_cloth_form_gray_qual100_490x490_PALETTE4.gif
4-color GIF file
File size: 4,890 bytes



Filename: abstract_cloth_form_gray_qual100_490x490_PALETTE2.gif
2-colorGIF file
File size: 2,319 bytes




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




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




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




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




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




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




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




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




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 that 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 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 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.)