Decrease color depth - use nearest color

[bflmpsvz]

Hi,
Is there any plugin or workaround allowing to decrease color depth using palette and real "use nearest color" procedure?

I have problems in two typical situations:

1) I have True color (24BPP) image containing only 256 (or less) colors. IV function "Decrease Color Depth"/256 Colors
reduce substantially number of unique colors, because it use some RGB-565 algorithm, although it is not necessary when only 256 colors is used.
Even when I try "Import palette" function, using palette containing exact the same colors as the image, (and Options->Properties->Browsing/Editing->Import palette: Use nearest color is checkded), the result is the same. (Except that reduced image has now complete palette, but most of its colors are ignored and not used in the image). Probably the same RGB-565 algorithm is used first, and only than nearest colors from palette are compared.
For instance, here is 8BPP image with 256 levels of red. If I increase color depth to 24BPP a than decrease it back to 8BPP, IV reduce number of colors to 32. (i.e. 2^5 . In case of green, it would be 2^6=64 colors)


2) I have True color (24BPP) image with more than 256 colors, and I want to decrease color depth to 8BPP/256 colors, and I want to keep some colors unchanged (pure white, pure black, transparency color, windows colors, human skin colors etc.), while others are not important.
I would like to use "Import palette" function together whith my own palette and keep this way important colors unchanged, but again, that RGB-565 algorithm make it impossible.

What to do? I suppose that it would be easy to create some plugin, which accomplish simple "use nearest color" task without that RGB-565 reduction...

[Mij]

What you describe is well known. It has been discussed here on a number of occasions. I agree that the "Decrease color depth to 256 colors" feature behaves poorly. I discussed it some time ago with Irfan Skiljen and he agreed to adding as an optional alternative the Xiaolin Wu algorithm, which I believe is a much better choice. However it is a long way down his "to do" list and I do not think it has any priority.

Meanwhile if you want to see how Xiaolin Wu performs you can make use of the Riot plugin. Open your 24bpp image in Irfanview and choose File > Save for web which opens the plugin. If it is a big file it will invite you to resize it down before entering. Best to do so for your first try because then you can make sure the settings are left in the right state to avoid long waits when you do go in with a big one.
In the Riot dialog choose
File type - click on PNG
Color quantization algorithm - Xiaolin Wu
Color reduction - Optimal 256 Colors Palette
Reduce colors to - 256 (or less if you wish)
Avoid Best compression or Neuquant neural net for very large files. They can be agonizingly slow.

You cannot send the result back to the browser. You will need to save the file and then open it again in Irfanview to see what it has done and compare the result with the algorithm built in there.
Incidentally always make sure you are viewing at 100% zoom (1:1) in the browser if you are examining the colors of pixels. If the image is zoomed higher you may see some color artifacts that are not in the true image.

[bflmpsvz]

Hi,
thanks for the answer. Xiaolin Wu algorithm is interesting, but I have more often the problem 1), which doesn't need any algorithm. And even in case 2), I would prefer my own palette (no matter how I get it) and "use nearest color" using the simplest color distance formula. So I would be happy with an option "Do not use RGB-565 algorithm in process".
BTW, it seems to me that NeuQuant neural-net algorithm works much better with my test image, though "No algorithm at all" would be the best:
The original 8BPP, 217 used colors:

8BPP created by Xiaolin Wu algorithm - visible bands, only 61 used colors

8BPP created by NeuQuant neural-net algorithm, looks good, 149 colors used (but filesize is larger than original!)

[Bhikkhu Pesala]

It beats me why so many people expect to be able to use a free image viewer for all photo-editing tasks. What's wrong with using PhotoShop or some other tool that's designed for the task — I heard that there are really good free tools out there.

I don't usually recommend products that I haven't used myself, but I often see Photo Filtre recommended here.

[Mij]

In this case, for your problem 1, I think you need Faststone image viewer. That seems to leave the colors unchanged when you reduce an image with 256 or less colors to an 8BPP palette.

I think just counting colors after conversion can be a bit misleading. Better to look at the Red channel histogram to get some idea of what the algorithm is doing to your image.

[bflmpsvz]

Yes, Faststone is able to solve the problem 1, but not the problem 2.
So I decided to create my own application, mainly to show that this is relatively easy, hoping that in future IV will contain this functionality too.
My application is based on sample program Dibble from the book Programming Windows by Charles Petzold
(original: http://examples.oreilly.com/97815723...Chap16/Dibble/ )
This program for simple image-processing contains about two dozens of procedures for creating of palettes. I added one which use the first 256 colors
found in image. So, if there are 256 colors or less, all of them are contained in the palette.
It was almost all I had to do, because procedure which converts formats from 24bpp to 8 bpp use API function GetNearestPaletteIndex, which do exactly
what the name say. This is the genuine "use nearest color" function, which I miss in IV.
Now, what is it good for? I have total control over palette, when I need to convert from 24bpp to 8 bpp, either when I need to decrease an image filesize,
or I want to use it in animated gif.
For instance, I have this image, and I want to keep colors of the window and its content, except the blue title bar:

The image has 421 colors. The blue bar contains 191 colors, the rest 230 colors, so I want to reduce those 191 blue shades to 256-230=26 colors. I cut the blue bar off and I reduced (in IV) its representative part
to 26 colors and returned it to the image. I got collage containing 256 colors. The palette generated from this collage I used to reduce the original image by that genuine "use nearest color" procedure.
Now 230 colors are unchanged and the title bar is reduced to 26 blue shades.

Another example. This image has 60035 colors:

I want to reduce it to 64 colors. IV do it this (bad) way, because too many palette colors are wasted to (unimportant) green and blue:

I assembled collage from important parts, reduced independently, and green and blue have reserved only 4+4 palette colors:

And the result is much better:

Animated gif can use particular palette for every frame or one palette for the whole animation. The second possibility gives usually smaller filesize. Here is gif with one palette containing 64 colors,
created the way explained above. I think it still looks good. (Why the hell is attached animated gif converted to jpg??

[Mij]

That's interesting. Which procedure are you using to reduce the number of colors using the Windows API? According to Irfan he uses the Windows API in Irfanview for the "Import palette" feature if you have "Import palette: use nearest color" checked in the Browsing/Editing tab of the Options. I had a long email discussion with him about that feature last year on behalf of another forum user. It does not produce the results you get though.
You can use "Import palette" instead of "Decrease color depth" by supplying your own custom palette but it is not much use for what you want to do. It looks as though Irfanview uses the "Decrease color depth" feature first to reduce the palette size and then changes the colors in that palette to yours using the Windows API.

[bflmpsvz]

I have found workaround for the problem 1! If I have 24bpp image with less than 256 colors and I save it as .png, IrfanView reduce it to 8bpp. When I open it again, I have 8bpp image with complete original palette! (And if the image has 16 or less colors, png is reduced to 4bpp, if less than 2 colors to 1bpp, with original colors in its palette)

That's interesting. Which procedure are you using to reduce the number of colors using the Windows API? According to Irfan he uses the Windows API in Irfanview for the "Import palette" feature if you have "Import palette: use nearest color" checked in the Browsing/Editing tab of the Options. I had a long email discussion with him about that feature last year on behalf of another forum user. It does not produce the results you get though.
You can use "Import palette" instead of "Decrease color depth" by supplying your own custom palette but it is not much use for what you want to do. It looks as though Irfanview uses the "Decrease color depth" feature first to reduce the palette size and then changes the colors in that palette to yours using the Windows API.

I still do not understand the way which IrfanView use for Decrease Color Depth. If I have image like that in my first post in this thread, red value of colors changes in step of 8. Even image with 2 colors for instance (96,0,96) and (103, 0, 103) is reduced to one color (100, 0, 100) no matter if I use "Decrease Color Depth" or "Import Palette" with all 256 magenta colors (x, 0 , x).

So I supposed that all colors are in RGB565 space. But if I try to reduce sample of image, containing many similar colors and I let IrfanView to reduce it let say to 32 colors or less, RGB values does not keep that RGB565 space, and that is why I can use IrfanView to reduce image per partes and create collage containing desirable colors, which I use for creating palette and than (using API function GetNearestPaletteIndex) for reducing the original image to 8bpp.
So I still use for color reduction IrfanView, but in small steps. If I used another program using different algorithm for those steps, maybe results could be even better, who knows?

[Mij]

I cannot help explain why IV still uses the Decrease Color Depth algorithm that it does, other than that the program author, Irfan Skiljen, appears to like it. I presume that it was reasonably fast in the days when computers were much slower. It also allows the option of using Floyd-Steinberg dithering.
It seems to me to almost invariably produce poorer results, with or without the dithering, than the more modern algorithms used by almost every other program and many users here have complained that colors are changed even when there is no apparent need. I had not realized that it was trying to fit the palette to RGB565 color space but now that you point it out that is clearly what it is doing. So I presume it also had advantages in terms of memory and disk space used when that was more important than it is today.
I suppose we will just have to continue using workarounds until it does get to the top of Irfan's "To do" list, if ever that happens.

[Mij]

Thanks Irfan!

Well it got to the top of the list quicker than I expected. Decrease Color Depth in v4.36 certainly seems much improved and the results from your images appear to be a lot better, bflmpsvz.
What do you think?

[bflmpsvz]

I think it is really good!

[bflmpsvz]

I have found workaround for the problem 1! If I have 24bpp image with less than 256 colors and I save it as .png, IrfanView reduce it to 8bpp.

But only using PNGOUT plugin, with default setting Bit Depth:Auto

[bflmpsvz]

IV & Palette size in GIFs

Does anybody know why IrfanView, when saving GIF, use only palette size 256, 16 or 2 colours, when it is possible to save 256, 128, 64, 32, 16, 8, 4, 2 colors?

Let's say I have this picture, saved by IV, containing only 32 colours:

It's filesize is 1401 bytes. IV used 256 colours palette, which is mostly empty.
In IV it can be checked by F3 - Show HEX view function. Palette occupies 256x3=768 bytes from 0Dh (13) to 030Ch (780). When I manually delete (using some binary editor) those (256-32)x3 zeros,
and change byte on the position 0Ah (10) from F7 to C4 (Color Resolution, Size of Global Color Table), I have the same picture, but smaller in filesize:

It's filesize is 729 bytes.
I suppose, that it's format is absolutely O.K. and that it has sense, in case of small pictures, use appropriate palette size.
(I use IV Version 4.36)

[Mij]

I assume that it is not worth the effort of using the full range of palette sizes when the saving in file size is very small.
As an example I took a typical 7.95MP 24bit color image with a size in memory of 22.7MB.
I then reduced color depth to 256, 32 and 16 colors in Irfanview and saved them as 3 GIF images with LZW compression set to 6.
All 3 of course still have 7.95MPixels and differ only in color depth.

The resultant file sizes were respectively:
256 color GIF - 2.92MB
32 color GIF - 1.10MB
16 color GIF - 617KB

So despite having a 256 color palette, the 32 color GIF is only 37.9% the size of the 256 color one. One might expect that 7.95million 5-bit numbers might become 62.5% the size of 7.95million 8-bit ones but clearly the LZW algorithm manages to compress them more effectively as well. The potential saving of 224 bytes (256-32) by using a smaller palette is hardly worth bothering about in comparison.

I should perhaps mention that the original full color image when saved as a JPG file at a quality setting of 80 was just 907KB, so if the image quality is good enough for you, Jpeg is pretty hard to beat.

[bflmpsvz]

I assume that it is not worth the effort of using the full range of palette sizes when the saving in file size is very small.
As an example I took a typical 7.95MP 24bit color image with a size in memory of 22.7MB.
I then reduced color depth to 256, 32 and 16 colors in Irfanview and saved them as 3 GIF images with LZW compression set to 6.
All 3 of course still have 7.95MPixels and differ only in color depth.

This is extremely bad example. Nobody would use LZW compression for such kind of image. LZW is for drawings, which contain large regions of the same color.
Try to save 4 color american flag. GIF or PNG is pretty hard to beat, and the compression is lossless.

So let's keep to my own examples. I am interested in making of animated GIFs, that is why I study now this and only this image format.