At 2:45 PM +0100 13-03-00, PalmPilot ml user wrote:
>could it be that the "WinRGBToIndex" call is very slow ?
It can be. But there are some optimizations.
The current algorithm is:
1) Check the slot in the colorTable referenced by the 'index' value in the
passed RGB structure for an exact match. (This is a big win when you're
validating a colortable after just one entry in the palette has changed.)
2) Check to see if the last entry in the table is an exact match. (The
last entry is black in all the default tables. By doing this check first,
we make sure that black always matches the last entry, and thus the index
value has all the bits turned on... this is important for old code that
does XOR inverts.)
3) Check the entire table to see if there's an exact match for your RGB
value. (This is a relatively fast loop, because it just does a mask and
compare.)
... by now we're usually done. Or will be if you're using a RGB value
that's in the palette. This part has been fast.
So if we go to the next step, it means we have to do an inexact match,
which means doing some color fitting. And this is necessarily slower.
The algorithm first attempts to do an intensity match. That is, it
computes the intensity value of the RGB color = (2*red + 5*green + blue)/8,
and compares this value with the reference color table brightness values.
It will keep doing this as long as the Red, Green, and Blue values in each
color table entry are all equal.
Said another way, we do intensity matching if and only if the reference
colortable is strictly grayscale. That's normally the case in the 1-, 2-,
and 4-bpp colortables.
As soon as a non-gray value is found in the reference color table, we break
out of the intensity loop and switch to a (costlier) RGB comparison. In
the default 8-bit colortable the 2nd reference color is not a grayscale
value, so in practice we break out of the intensity loop very quickly.
If we've gotten this far, we have to do a color best fit. The current OS
uses a shortest distance in RGB space algorithm. That's not perceptually
perfect, but it's reasonably fast and good enough.
The RGB distance is computed by squaring the differences between the Red,
Green, and Blue values in the passed table and each entry in the reference
table. The reference table entry with the lowest distance is considered
the best match. This loop is carefully written to do only (short) integer
math, so it's reasonably fast, though there are three multiplications for
each color table entry, so in the 8-bpp case that's 768 multiplies, which
is a fairly significant cost.
--Bob
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
