The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion Algorithm to find nearest color

From:
To:
Cc:
Followup To:
Subject:
 Validation: For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon.

More options Jun 26 2012, 4:22 pm
Newsgroups: comp.graphics.algorithms
From: Nobody <nob...@nowhere.com>
Date: Tue, 26 Jun 2012 21:22:32 +0100
Local: Tues, Jun 26 2012 4:22 pm
Subject: Re: Algorithm to find nearest color

On Tue, 26 Jun 2012 11:11:50 -0700, Guilherme Utrabo wrote:
> In my application I have a list of RGB colors. The user then chooses one
> color and I have to find the nearest color. I know there is more than one
> method to do this, using hue and saturation, etc. That's not what I need
> help with. My problem is to find an optimal algorithm to find the nearest
> color. Today my approach is very straight foward, but lacks performance:

> Get the RGB for the user color. Then I sort my list by the sum of the
> absolute difference of the RGBs. I do that directly on the database using
> SQL, but I can do it in the code if I find a better way. I'll post the SQL
> code just for reference: SELECT TOP 1 * FROM COLORS C ORDER BY ABS(C.Red -
> UserRed) + ABS(C.Green - UserGreen) + ABS(C.Blue - UserBlue) DESC

> Do you guys suggest me an algorithm to do that search? Thanks for your
> help.

If you need to do many lookups against a fixed set of colours, the fast
solution is a lookup table, but it requires 2^24 ~= 16 million entries for
a 24-bit colour.

If you can't afford that much memory, then use a coarser lookup table
which only uses the top N bits of each component and which maps any
colour to a list of "candidate" colours.

If you don't perform many lookups or if the list changes frequently, then
it's a tradeoff between optimising the lookup time and optimising the time
to modify the list, which depends upon the relative frequency of the
operations.