Lossless Image Resizing in C# - Color Quantization
(Page 2 of 6 )
Let's remind ourselves of the way we defined quantization and why it is necessary for GIF conversions. First, we all know that JPEG images are full-colored and that the format is able to store 24 bit images with the appropriate palettes. This means that when you want to display a 24-bit or higher bit JPEG image on 8-bit hardware, for example, the image viewer application quantizes the colors to 8 bit.
Thus, the display process becomes drastically slow - of course, this depends on the hardware of the system as well as the algorithm that's used by the image viewer. In a nutshell, color quantization stands for color reduction, so it matches the hardware capabilities and therefore the system is able to display the images.
Needless to say, we are living in a generation where having 24-bit colors is "the norm," so this isn't an issue with JPEG and other formats. Fortunately, by their very nature, as I explained before, they can support up to 24-bit and more colors. That's why our JPEG, PNG, BMP, etc. images are so razor sharp and high quality.
But the scenario is different in the case of GIFs. The GIF format was designed with weak system performance in mind, especially 8-bit or less color display possibilities. Due to this, by definition the GIF image format doesn't allow more than 256 color palette entries; each palette contains a specific number of colors. This means that an image saved/converted to the GIF format cannot contain more than 8-bit colors.
You see, the aforementioned fact explains why color quantization is a must when we convert higher than 8-bit colored images to the GIF format. The GDI+ of the .NET environment is optimized for speed and because of this, it sort of neglects image quality. Thus, the default quantization algorithm incorporated by Microsoft, unfortunately, produces pixelated and low quality images.
The quantization algorithm is very dependent upon the source image. Sometimes is looks quite acceptable, other times the image becomes almost totally destroyed due to hundreds of misplaced and wrongly colored pixels, resulting in all-around pixelation.
In the first part of this series, I attached a comparison picture where an original 24-bit JPEG image is compared to an 8-bit quantized image done with the GDI+ standard algorithm. It turned out quite awful. Here we show another example. The results are "acceptable," but the loss is clearly visible.
(The left photo is 24-bit original JPEG while the right one is the quantized 8-bit GIF.)
In a nutshell, quantization is necessary each time we work with GIFs because by the format's very nature it cannot accept more than 256 colors. Therefore, we need to design a quantization algorithm which reduces the original source image's bit-depth to 8-bit. Developing a high-quality color quantization algorithm from scratch is a black art and a very complicated process. Add to this the fact that there does not exist an algorithm that is optimal for every possible image. It is impossible.
As we've presented here, it is clear enough that in this era of computing GIFs are quite obsolete. That's why nowadays you don't really come across the GIF format, excluding the cases when the GIF in question is animated. Animations of 8-bit or less are acceptable, since their size grows linearly to the number of frames anyway.
Notwithstanding, we don't want to leave this part unresolved in our application, so we brainstorm for a solution. Searching Google for "good color quantization algorithm" is a way to find answers. I have come across Wesley Bakker's Better Image Processor [BIP] project that is freely distributed in its DLL form at his site. You can download the whole BIP in its entirety containing 3 DLLs, but we are only going to need one of them.
Next: Getting Started >>
More C# Articles
More By Barzan "Tony" Antal
/ 11 
