Hi all,
I've found that a good way to get decent performance out of WinRGBToIndex is
to make sure that the RGB you're checking fits:
> 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.)
... by making sure that all three components are divisible by 51 (these are
the web-safe colours). Do something like
red = (red/51)*51;
green = (green/51)*51;
blue = (blue/51)*51;
as long as the vars are integers, and things go a whole lot faster. The
price is that you'll miss the opportunity to use some of the intermediate
greys and other extra colours.
Seeya,
David
---
David Oakley - [EMAIL PROTECTED] - ICQ 9610512
partner, Astraware - http://www.astraware.com/
New: Zap!2000 for Palm: http://www.astraware.com/palm/zap2000/?dsig
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Bob
> Ebert
> Sent: 13 March 2000 20:08
> To: Palm Developer Forum
> Cc: Palm Developer Forum
> Subject: Re: WinRGBToIndex slow ?
>
>
> 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
>
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html