phospholipid -
A suggestion, and then a question followed by a suggestion ...
#1:
If I understand you correctly, you essentially want to perform automated color identification on images of hairy, fuzzy fibers, If this is indeed the case, because of shadowing of one thread by another, there will be large differences in brightness from one pixel to the next, but the hue, and to a lesser extent, the saturation does not vary so wildly. Below, I attached the original, Hue, Saturation, and Lightness images, in that order, for an example textile pattern that I found on the web.
Put differently, as you move from one pixel to the next within an area of one type of fiber, the R, G, and B values will all go up and down by large amounts, but they will do so, more or less proportionally. Such large swings in all the numbers will make anything but the coarsest discrimination almost impossible. In contrast, if you use just the hue, or a combination of the hue and saturation as the basis on which you classify the fibers, this method will be able to make much finer, more reliable distinctions between one type of fiber and another.
So, my first, very strong recommendation is that you switch from an RGB based method to an HSB or a L*a*b representation of the images (ie, and intentionally disregard the B, L, or V component in your classification process).
---------------
#2:
Is it correct to assume that within each image, there will only be a few different types (colors) of fibers. In other words, is it safe to assume that you will never have dozens, and certainly not hundred of different types of fibers in each image?
If the above assumption is true, then your indexed color method of classification will be much more prone to misclassification errors than other methods. Specifically, the indexed color method is almost certainly going to tell you that the image contains many different variants of each of the small number of colors that actually are present. Although it will be an improvement, even if you switch over to a HSB or L*a*b classifier as suggested above, you will still run into this problem.
Here's a simple way to understand why this will occur: Suppose the only variation between fibers is hue (so that we can completely ignore saturation and brightness for the moment). The indexed color method is essentially dividing up the hue axis into hundreds of different bins, and then placing each pixel in each bin (which represents a different indexed color). Since, I presume, there are only a few different types of fibers in each image, if you constructed a histogram of this, you would only see a small number of distinct peaks, each of which is almost guaranteed to be many bins in width. So, it may be obvious to you that there are only, say, three different types (colors) of fiber in that image, but the indexed color method will likely say that there are dozens of types. I don't think you want this.
A much less error prone classification procedure would be to first calculate the center of each of these peaks (in the hue histogram mentioned above). Because of the large number of pixels contributing to each of these peaks, the average hue of each peak can be calculated with vastly higher accuracy than any one measurement. Then you simply find the color in your catalog with the nearest hue.
If you are interested in this method, I can tell you how to pursue it. Most likely, it would involve very little (or no) programming on your part because color classification is an extremely common problem in many fields, and software exists that already does most, if not all of what you need. For example, take a look at this ImageJ page, and move your cursor over each of the small pix on the RHS of the page. Most of these examples from biology are doing almost exactly what you want to do. For example, many employ a technique called "k-means clustering" to find the centroid of each of the peaks in not just one dimensional histograms (eg, hue only), but in 2D histograms, as well (eg, hue and saturation, or "a" and "b" from L*a*b).
OTOH, if my initial assumption (ie, only a few different types of yarn are used in each image) is wrong, then ignore the approach that I just suggested because if dozens or hundreds of different types of yarn are in each image, my method won't offer much improvement over an indexed color method.
HTH,
Tom M
