# GetNearestPaletteIndex too slow

• 02-13-2009
baccardi
GetNearestPaletteIndex too slow
GetNearestPaletteIndex is very slow, are there any algorithms that i could implement in order to optimize these actions and get the same results as with GetNearestPaletteIndex?
• 02-13-2009
brewbuck
Quote:

Originally Posted by baccardi
GetNearestPaletteIndex is very slow, are there any algorithms that i could implement in order to optimize these actions and get the same results as with GetNearestPaletteIndex?

Depends how GetNearestPaletteIndex() is implemented, and depends on what the definition of "closest color" is. It might already be as fast as reasonably possible.

One possible quantization algorithm if you already have a palette, is to represent the palette as an octree (a tree that branches 8 ways). This represents the 8 octants of the 3D colorspace. Each palette color is inserted into this octree by recursively subdividing the parent octant, proceeding until you reach some maximal depth. A good heuristic cutoff is the number of palette entries per leaf.

Then, to quantize a color, you walk the octree as if you were walking a binary tree, but in this case you are branching 8 ways. When you reach a leaf, find the closest palette color in that leaf and use it.

But I don't know what Windows does. If Windows is already doing something like this, you aren't going to improve on it that much.
• 02-14-2009
baccardi
want to know how i solved the problem? Because i'm going to convert several bitmaps a second (i'm writing desktop viewer) i need to make it fat but program initialization may be slow, so i made a buffer colorTable and put all the indexes representing all the rgb values, colorTable size is 0xFFFFFF so when i need to get a color index from rgb value i just do like this:
index = colorTable[rgb] and i managed to optimize the conversion from 1,1s to 32 miliseconds. And the program initialization takes about 32 seconds but that's not a big problem because it's done only once