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.
|
! Note !
Text, images, file-size-data, or links may be added
or improved --- if/when I revisit this page.
|
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.
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.
-
The entire GUI window is captured as a PNG file
using the 'gnome-screenshot' utility ---
on Ubuntu 9.10 Linux.
.
-
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.)
-
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 :
-
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.
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
-
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.)
-
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
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.
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.
|
START of IMAGES for the
'color-compress-to-GIF' experiments :
(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 ...
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.)
Page was changed 2024 Jun 19.
(Changed links to other web pages so they load in a separate
window or tab so that this page remains available in its window or tab.)
|