I am trying to write an algorithm for detection of the color green. The thing is that if I try detecting the shade of a pixel in a picture, there are more than a million different shades possible. How do I sift thourgh all these different shades and detect which ones are green ? Does anyone know of a simple way to do it or of any prevelant algorithms that does it for you ?
Assuming that your picture uses some form of RGB format to store the color for per pixel, you can distinguish if the color of a pixel is green if both red and blue colors are zero.
One of the most popular methods used for this puprose is using the vector distance. I've used this in the past for detecting colors and it works fine. Here is a brief explanation:
Let's say you are searching for "green" pixels. Pure green exists when the values of the pixels are:
R = 0
G = 255
B = 0
Though, when searching for green you may want to have a "tolerance" meaning that you don't only search for pure green, but also for some other green-like combinations. Suppose that each pixel is a vector: pixel = [R G B]
Also, the color combination you are looking for is another vector: green = [0 255 0] (reference color)
The eucledian distance between those 2 vectors is: D = sqrt((R-0)^2 + (G-255)^2 + (B-0)^2)
(in the place of 0 and 255 you can place whatever you want, according on the color combination you are looking for...)
So the algorithm goes:
Code:
for each pixel
{
1. compute the distance between that pixel and the reference color (D)
2. if D<Threshold
then
current pixel is accepted
else
current pixel is NOT accepted
}
PS1: "Threshold" is a constant value and has to bee set manually according on the "tolerance" you want to give to your algorithm (a high value of Threshold means that also less "clear" green pixels will be considered as green, whereas a lower value of Threshold will make the algorithm quite "strict").
PS2: Threshold can also be computed using addaptive algorithms but this is quite difficult
PS3: I've tested this simple algorithm using Matlab and it works fine, so if interested tell me to send you the code.
I think you should give more tolerance to the brightness. To do so, norm the color vectors by 1 and then distance is distance between the resulting vectors+some cooff*difference in length.
"Programs must be written for people to read, and only incidentally for machines to execute."
Nice idea RoboTact. Though, that depends on what the seach is done for. Maybe the user doesn't want to give tolerance to brightness. But if he does, then you are right, that by normalizing the RGB coefficients he achieves that.
Another way to do this is to execute histogram equalisation in each coefficient (R,G,B), or even better to transform the RGB matrix to HSI and perform histogram equalisation to the I coefficient only.
Assuming you receive pixel values in RGB form, another option is to convert the color to HSV (Hue - Saturation - Value). Pure green has (I believe) a hue value of 192.
This would make it easier to weight saturation and light levels differently than hue.
--
Scott
with a screen that is 32 bit you use this (this is how I get colours from a direct draw surface)
long colour = (*(reinterpret_cast<long*>(ddsd.lpSurface)+(Y*Xres+X)))&0x00FF00
&0x00FF00 is a bit mask that will extract the green value so all you need to do is this
if(colour) //if true then there is some green in the pixel
there ya go be carefull with 16 bit numbers as some systems consider 16 bit to be 15
(ddsd.lpSurface is a void pointer to the beginning of the screens memory address, which is why it needs to be reinterpreted)
oh and in a 24bit BMP (just RGB no alpha) you have 16,777,216 different colours
In C, you merely shoot yourself in the foot.
In C++, you accidentally create a dozen instances of yourself and shoot them all in the foot. Providing emergency medical care is impossible, because you can't tell which are bitwise copies and which are just pointing at others and saying, "That's me, over there."
Assuming you receive pixel values in RGB form, another option is to convert the color to HSV (Hue - Saturation - Value). Pure green has (I believe) a hue value of 192.
This would make it easier to weight saturation and light levels differently than hue.
--
Scott
Also: hsv is sometimes better to use for color detection problems. For example, it is prooved that for human skin color detection, hsi (or hsv) model is much better, because it is closer to human color perception.
In C++, you accidentally create a dozen instances of yourself and shoot them all in the foot. Providing emergency medical care is impossible, because you can't tell which are bitwise copies and which are just pointing at others and saying, "That's me, over there."
Whereas RGB represents the Red, Green and Blue components of a color, HSV represents the Hue, Saturation, and Value (light- or dark-ness) components. Some feel it is a better match with the way humans think about color. You can covert RGB colors to HSV using the algorithm found here: http://www.cs.rit.edu/~ncs/color/t_convert.html
--
Scott
HSV and HSI are 2 very similar color models. HSV stands for:
H (hue): Ranges from 0-360. In some cases it is normalized 0-100. Hue represents the COLOR type (e.g. blue, red etc).
S (saturation): Ranges from 0-100. It represents the "purity" of the color: the higher saturation value is, the clearer the color is. If saturation is low, the color looks closer to gray.
V (value): This is the brightness of the color, and it ranges from 0-100.
HSV model is sometimes represented as a cone. Try find a tutorial for explanation on this.
How to convert from RGB to HSV:
Suppose you have (R,G,B) values:
MAX = max(R,G,B)
MIN = min(R,G,B)
then:
H = ((G-B)/(MAX-MIN))*60 if MAX = R
(2+(B-R)/(MAX-MIN))*60 if MAX = G
(4+(R-G)/(MAX-MIN))*60 if MAX = B
S = (MAX-MIN)/MIN
V = MAX
Reply With Quote
be carefull with 16 bit numbers as some systems consider 16 bit to be 15 
Originally Posted by wsmmi6674
Bookmarks