How is the ColorLearn color spectrum calculated?

[Chris C G]

Can anyone give me the details of how a single color is converted into a value in the color spectrum?

In other words, for an image that is a 2-D array of RGB values (or HSL or whatever) how is the 1-D color spectrum array produced?

I presume that the value of each element in the resultant color spectrum array is proportion of pixels with a 'color value' value equal to the index (which appears to be between 1 and 57).

But how is each point in color space (i.e. all 256x256x256 distinct colors) converted to a number between 1 and 57?

[DjDaveNI]

Hello Chris C G,

Upon examining ColorLearn Example.VI, an example that ships standard with LabVIEW Vision (LabVIEW\examples\Vision\2. Functions\Color\ColorLearn Example.vi), I determined that the ColorLearn VI changes the array of RGB values of a selected part of an image into either 16, 30 or 58 ranges and ranks the percentage of each range in the region of interest. The numbers 16, 30 and 58 correspond to the color sensitivity setting that the user specifies. By attaching an Indicator to the Color Spectrum output of the ColorLearn VI, one can monitor the color intensity percentage of a selected region of interest at a given color spectrum value. This is how the 1-D array value is created.

[Chris C G]

Hi there David,

Thanks for the reply. I realise now that I should have perhaps clarified myself a little better. I have been working with the ColorLearn VI set to high sensitivity, so my questions were in relation to that.

Consider the following situation:

The color spectrum produced by the ColorLearn VI (on high sensitivity) will be an array (with 58 elements). If I have a ROI that contains only pixels of a certain RGB value (or HSL, or whatever numerical representation one chooses), then the values of all the color spectrum elements in the array will be zero except for a single value (of 1) at a particular index. If the RGB value (of all pixels in the ROI) changes, the particular index of the non-zero element may change (but there will always be only one non-zero element).

What I basically wanted to know was how that index for the color is determined? Any of the 16777216 possible colors (256x256x256) will get converted to a value between 0 and 57 (apologies for the 1-57 mistake in my first post). In other words, each color gets 'pigeon-holed' to one of 58 values (along with more than 289,000 other colors on average!)

mathematically: color spectrum index = f(R,G,B)

So, what is f(R,G,B)?

or, if it's easier to express, what is f(H,S,L), f(H,S,V) or f(H,S,I)?

Does my question make sense?!

Thanks in advance.

[BruceAmmons]

I played around with ColorLearn recently and I have a few guesses:

I would guess the bins are based on color wavelengths.  Each single color would be split between two bins if it falls between those two color wavelengths.  I think hue is the only variable of interest.

I would guess the results of ColorLearn is a histograph of all the pixel colors in the image, scaled to a sum of one.  If you have all green and blue pixels, you will get values only in those bins.  If you had a rainbow, you would have a pretty even distribution throughout the bins.

Like I said, all guesses, but you could easily verify if they are true.

Bruce

[Chris C G]

Hi Bruce,

Thanks for the help. I have already had a bit of a play to investigate my guesswork as to how the colors are binned, and came up with the attached VI (apologies for the poor layout etc.!)

I'm using nested for loops to work with all possible H and S values (using HSI coding) using a fixed intensity. As a result, I'm displaying outputs as two dimensional (I don't think very well in 3-D).

The top half of the block diagram creates a one pixel image for each colour and uses the results of the ColorLearn VI to feed into an intensity graph of the ColorLearn bin chosen (as a function of H and S).

The lower half of the diagram is really just eye candy to help me visualise what each of these H and S values actually look like by creating an image with a pixel for each color.

Assuming it works OK for you, you can probably see that there is definitiely a relationship between H and the color bin chosen, but it's not completely independent of S and I.

Also, there is presumably a formula that determines when the color should be binned as black or white (no greys allowed!) which are values 56 and 57.

That's as far as I got before deciding to post to the forum!

Cheers

Chris

[dnair]

Hi Chris, Chapter 15 (15-8) in the NI Vision Concepts Manual will give you a good overview of how the spectrum is calculated. Here is some information from the manual: " Each element in the color spectrum array corresponds to a bin of colors in the HSL space. The last two elements of the array represent black and white colors, respectively. The hue space is divided into a number of equal sectors, and each sector is further divided into two parts: one part representing high saturation values and another part representing low saturation values. Each of these parts corresponds to a color bin—an element in the color spectrum array." We use the saturation and luminance values (S and L) associated with a color to determine whether it is black or white. For example if the saturation value is very small and L > 128, then the color is classified as white and black otherwise. Hope this helps. Dinesh

[Chris C G]

Thanks for the link, but I'm still a little puzzled. I don't agree with the concepts manual that for a given luminance that the hue space is divided into equal sectors. For example, if you run the colorlearning VI I posted previously, and set the ColortoRGB VI to work with HSL input values, and set a fixed luminance (128 as described in the concepts manual), the sectors in hue space are not equally sized. As an example, for a given hue (H =195), as saturation varies, the color spectrum bin can be one of four possible values (46, 47, 49 or 51) plus black or white. If you use HSI input values, the concepts manual is almost right, except that (for a fixed hue) the saturation value for which transition from one bin to the next is not fixed, i.e. it is wrong to represent the inner sectors ('low saturation bins') in Fig 15-5c as a circle (constant radius). Am I mistaken?

[DjDaveNI]

Hello Chris C G,

I am working with our Vision Product Experts to come up with an answer for you as soon as possible. I will post to this forum tomorrow and let you know what I find out. Thanks for your patience.

[dnair]

Hi Chris, Attached is a VI that creates a color image with Hue = 195, L = 128 and varies the S value from 0 to 255. One of the graphs outputs the bin number for each S value. You will see that the for very small values (S < 10) the color is classified as white because L = 128. The VI uses the default Saturation Threshold of 80. The Saturation Threshold value is the value that breaks up the Hue sector into two bins. From S = 10 to S = 79, the color spectrum bin is 46 and from S = 80 onwards the bin is 47. In your VI you start with a HSL value, convert it into an RGB image and then pass it to the Learn Color Spectrum VI. The learn VI internally then converts the image back to the HSL space to compute the spectrum. Conversion between HSL and RGB color spaces is not linear and this may explain the results you are seeing. Dinesh

[Chris C G]

Thanks for that info. I didn't realise about the transformations between RGB and HSL, so I was searching for an explanation in the wrong place. You guys have been very helpful, thanks.

Actually, it raises a few interesting questions in my mind about how an image would appear when transformed back and forth between HSL and RGB space.

Perhaps I'll look into that some other time... 🙂