Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
comp.graphics.algorithms
+ new post
About this group
Subscribe to this group
This is a Usenet group - learn more
Message from discussion Algorithm to find nearest color
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
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. Listen and type the numbers you hear
 
Nobody  
View profile  
 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
Print | View thread | Show original | Report this message | Find messages by this author

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.


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google