Yup, right now Spriter is only calculating the Euclidean distance in RGB colour space to all DMC threads and taking the minimum. I've been considering weighting the dimensions, in case we as human beings are more sensitive to differences in green than red, for example; but I don't yet know whether such a bias exists for RGB (or I should say, I haven't yet bothered to looktbsp wrote: After looking at it further (and assuming you likely just use the "nearest point" in the RGB space), it seems the program I'm using to do color reduction before running the image through Spriter (Irfanview) is tweaking the colors just enough to make the colors I don't want the nearest matches. I've tried two other programs, but they're doing even worse. The variation in results when reducing the same image from 57 to 34 colors in various programs is quite interesting.
Unfortunately my best results still seem to be with Stitches (OSX), which is doing such a good job (imo) at reduction/matching that I suspect it's somehow reducing colors with the DMC thread color space taken into consideration. I say unfortunately because that software carries an $80 price tag and doesn't produce very readable charts.
).Regarding colour reduction, it makes the most sense to me to reduce in DMC colour space rather than the original RGB colour space. I'm also considering weighting the reduction algorithm by the thread count of each colour - based on the premise that if one must eliminate a colour, it might as well be one that is used for only a handful of stitches as opposed to one making a big swath. I'd like to make Spriter competitive with other programs, but of course this is just a hobby of mine so the pace of development scales accordingly
Thanks for your input!
Cheers,
- sd.
Let me know if you run into any problems! I like getting the feedback 
Someone once talked about a colour name instead of number, so to find out what they were talking about, I had to look them up.