image color conversion

I need to convert 24bppRGB to 16bppRGB, 8bppRGB, 4bppRGB, 8bpp grayscal and 4bpp grayscale. Any good link or other suggestions?

preferably using Windows/GDI+

[EDIT] speed is more critical than quality. source images are screenshots [EDIT1] color conversion is required to mini开发者_如何学Gomize space

You're better off getting yourself a library, as others have suggested. Aside from ImageMagick, there are others, such as OpenCV. The benefits of leaving this to a library are:

• Save yourself some time -- by cutting out dev and testing time for the algorithm
• Speed. Most libraries out there are optimized to a level far greater than a standard developer (such as ourselves) could achieve
• Standards compliance. There are many image formats out there, and using a library cuts the problem of standards compliance out of the equation.

If you're doing this yourself, then your problem can be divided into the following sub-problems:

1. Simple color quantization. As @Alf P. Steinbach pointed out, this is just "downscaling" the number of colors. RGB24 has 8 bits per R, G, B channels, each. For RGB16 you can do a number of conversions:
   • Equal number of bits for each of R, G, B. This typically means 4 or 5 bits each.
   • Favor the green channel (human eyes are more sensitive to green) and give it 6 bits. R and B get 5 bits.
   • You can even do the same thing for RGB24 to RGB8, but the results won't be as pretty as a palletized image:
   • 4 bits green, 2 red, 2 blue.
   • 3 bits green, 5 bits between red and blue
2. Palletization (indexed color). This is for going from RGB24 to RGB8 and RGB4. This is a hard problem to solve by yourself.
3. Color to grayscale conversion. Very easy. Convert your RGB24 to YUV' color space, and keep the Y' channel. That will give you 8bpp grayscale. If you want 4bpp grayscale, then you either quantize or do palletization.
4. Also be sure to check out chroma subsampling. Often, you can decrease the bitrate by a third without visible losses to image quality.

With that breakdown, you can divide and conquer. Problems 1 and 2 you can solve pretty quickly. That will allow you to see the quality you can get simply by doing coarser color quantization.

Whether or not you want to solve Problem 2 will depend on the result from above. You said that speed is more important, so if the quality of color quantization only is good enough, don't bother with palletization.

Finally, you never mentioned WHY you are doing this. If this is for reducing storage space, then you should be looking at image compression. Even lossless compression will give you better results than reducing the color depth alone.

EDIT

If you're set on using PNG as the final format, then your options are quite limited, because both RGB16 and RGB8 are not valid combinations in the PNG header.

So what this means is: regardless of bit depth, you will have to switch to index color if you want RGB color images below 24bpp (8 bits per channel). This means you will NOT be able to take advantage of the color quantization and chroma decimation that I mentioned above -- it's not supported in PNG. So this means you will have to solve Problem 2 -- palletization.

But before you think about that, some more questions:

• What are the dimensions of your images?
• What sort of ideal file-size are you after?
• How close to that ideal file-size do you get with straight RBG24 + PNG compression?

• What is the source of your images? You've mentioned screenshots, but since you're so concerned about disk space, I'm beginning to suspect that you might be dealing with image sequences (video). If this is so, then you could do better than PNG compression.

  Oh, and if you're serious about doing things with PNG, then definitely have a look at this library.

Find your self a copy of the ImageMagick [sic] library. It's very configurable, so you can teach it about the details of some binary format that you need to process...

See: ImageMagick, which has a very practical license.

I received acceptable results (preliminary) by GDI+, v.1.1 that is shipped with Vista and Win7. It allows conversion to 16bpp (I used PixelFormat16bppRGB565) and to 8bpp and 4bpp using standard palettes. Better quality could be received by "optimal palette" - GDI+ would calculate optimal palette for each screenshot, but it's two times slower conversion. Grayscale was received by specifying simple custom palette, e.g. as demonstrated here, except that I didn't need to modify pixels manually, Bitmap::ConvertFormat() did it for me.

[EDIT] results were really acceptable until I decided to check the solution on WinXP. Surprisingly, Microsoft decided to not ship GDI+ v.1.1 (required for Bitmap::ConvertFormat) to WinXP. Nice move! So I continue researching...

[EDIT] had to reimplement this on clean GDI hardcoding palettes from GDI+