[prknight]

Well this is funny and cool to see, I spent the better part of Sunday playing with the name that color script (http://chir.ag/projects/ntc/) and jPicker and I compiled a larger color list for it using a couple additional sources. That particular script's color list only requires the name and hex value of the color which is a little more compact. I don't see any other major differences though. It's handy to know that the Wikipedia list has duplicate values for different names (Chestnut Rose = Indian Red for example), looks like your script just grabs the first match it finds.

I was wondering what to do with darker colors as they are less represented in terms of color names. So, when you pick a random darkish color the accuracy reduces because there are less names to choose from.

I was thinking perhaps the best solution would be in these cases to extrapolate a lighter variation of the picked color and display that color with a measure of its darkness (30% darker purple). Right now, if you pick a color like #291c36 you'll get dark jungle green when it's a dark purple. Any thoughts on tackling that problem?

[Gauth]

I also noticed the problem with darker colors. I introduced several ideas in the article: using a different metric or a different colorspace. This could help, but if we really have a lower points density in the darker zones, the good solution might be to find even more colors on the internet.

Your proposed solution looks to be a mix of changing the color space and the metric. Maybe we could use HSL/HSV with a metric that reduces the weight of some component. It could therefore consider less the fact that the three components are high/low, but focus on the "real" color side.

[prknight]

Increasing the dataset of color names doesn't really work as well to address this problem in my opinion. I looked at a pretty large set of colors of 5000+ and I discarded it because it just introduced too many exotic sounding names only a color expert can tell apart - it wasn't an UI improvement and it still doesn't give consistent results for the darkest and lightest colors.

I think working with HSL values works better in principle. Just adjusting the lightness value can be used to arrive at a more sensible color description. The most common lightness values for color names hover around 50% (at least in the 3000+ dataset I compiled). One solution is to have a simple formula that takes in account how accurate the nearest color name match is and if it is too inaccurate, to find the color name for the color's HSL with the L adjusted to 50%. I guess you could call it staying true to the hue. I think that would make the color naming script even more useful though.

[Gauth]

One solution could be to use several points for each label (color name). For instance, we could use a limited set of color names (red, green, blue, etc) but have a lot of points associated to this labels. For example, different points like #07250b (that is, in my opinion, missclassified) and #51f665 could share a same label: green. The main problem is that I'm not sure It is possible to find such a dataset on the internet. Maybe we can build one from sites like http://cloford.com/resources/colours/500col.htm, removing the numbers from each color name.

With several points for each label, It will give us the possibility of using a 3NN, for example, instead of a 1NN classifier. It should impact also on the results, but I'm not sure it will really improve the results.