Comments by RanCohen (Top 6 by date)

None of the above - I got a ClassCastException in my program and couldn't figure out why the compiler didn't block me in the first place...
And why is CodeProject the wrong place to ask this?

Look at this for simplification as coordiantes in a 2D space. If I want to search for the closest match for (x1, y1), and assume that distance(x1, y1, 0, 0) is r1, I can look for the color with a distance to (0, 0) which is closest to r1. If the two colors distance is r2 between them, it means that the best possible match is between r1+r2, r1-r2 (its like a circle which has (x1, x2) in its circle and a radius of r2, and i am searching for the best match in that circle).
This is the same for a 3D space as well.
Is there an error in my logic?

I think I thought of a somewhat simpler method - I look at the pixel as a coordinate in a space, and thus matching pixels are the ones that have the minimal distance between them. So instead of running on three lists, I can sort the array by the pixel distance to (0, 0, 0), and then do what you suggested - running up and down on the closest pixel, until the difference in the distances is greater then the minimal distance so far.
This is basicly the same algorithem, only now i run on a single list instead of three different lists that have to be interconnected.

Let me see if I got it right - You are suggesting 3 lists: One sorted by R, G, B, One sortet by say G, B, R and a third sorted by B, R, G. I iterate the first until the difference in the R factor is greater then the total difference of the minimal RGB, Then I iterate the second list, then the third, with each time its faster then the last because the minimum is less in each iteration? It seems a good solution and its certainly less then iterating through the whole list, but is it realy much less then O(n)? Won't it be possible that in some cases i might run on most of the Red values before finding a match?