My previous attempts had all involved reducing each image to a weighted list of ‘popular’ colours. The search UI let the user pick from the web (216) palette, with only images possessing a healthy portion of that colour being returned in the results. At one time I even allowed users to select a secondary colour along with RGB/HSV/CMYK (synchronised) sliders, but that was as complicated to use as it sounds, so I let it go. The problem was that this ‘popular colours’ approach ignored the fundamental truth that people just don’t search for drab browns, faded yellowy-greens or most of the other colours which make up these palettes. From a colour-space perspective, when people say ‘colour’, they mean ‘hue‘.

So earlier this week (on the train) I set about re-writing the whole colour search feature to actually be a hue-based search feature (the word colour remains because ‘hue search’ just doesn’t light up anyone’s eyes, not even mine). After a few train trips and most of Saturday I had the hue-parsing algorithm implemented and had written a console app which re-indexed all the existing images in the library. I also updated the relevant portions of the batch uploading tool and the admin web site to be hue-aware. Things were going well, but I had only a vague idea of how the actual search UI would work.

Initially I thought another slider would be the best approach, but decided it was overkill after looking around at existing html slider implementations (yahoo UI library as a nice slider, but I didn’t want the added dependency for what is essentially a minor feature). Eventually I set about rolling my own control for the job. I think the hue picker widget and the hue search feature as a whole turned out really well, and will continue to improve as the number of images in the library grows.

Now I’m thinking of packaging up the  Hue Picker for free distribution. You know, just for kicks.