RGB values received from TCS34725
Moderators: adafruit_support_bill, adafruit
Please be positive and constructive with your questions and comments.
- jbyle
- Posts: 8
- Joined: Sat Dec 13, 2014 3:48 pm
RGB values received from TCS34725
Hello,
I recently got the TCS34725 sensor and I started doing some Java development to access the sensor and do color readings with some objects I have at home. The results I got were not what I expected. I had in my mind that the RGB values returned from the sensor should give back more or less the color of the object that was on the sensor. I was using an online RGB tool to show me the color based on the values I got back. I needed 8 bit RGB values in the tool so I only used the high bytes values of each color returned from the sensor. I know there is loss of accuracy but not in that way that the color not resembles on what was on the sensor. To double check that the application I wrote had not an issue, I used one of the example Python scripts to get me the rgb values but the result was similar.
For example I put a green paper on the sensor (see attached picture) and the result was the following : C: 52340, R: 12207, G: 24913, B: 11382
Well the sensor figured green was indeed the major color but when I put the result in the RGB tool it showed a complete other green (very dark) than what I expected.
Can somebody explain me these results or are my expectations way to high about the results ?
All ideas or explanations on my findings are welcome.
Jan
I recently got the TCS34725 sensor and I started doing some Java development to access the sensor and do color readings with some objects I have at home. The results I got were not what I expected. I had in my mind that the RGB values returned from the sensor should give back more or less the color of the object that was on the sensor. I was using an online RGB tool to show me the color based on the values I got back. I needed 8 bit RGB values in the tool so I only used the high bytes values of each color returned from the sensor. I know there is loss of accuracy but not in that way that the color not resembles on what was on the sensor. To double check that the application I wrote had not an issue, I used one of the example Python scripts to get me the rgb values but the result was similar.
For example I put a green paper on the sensor (see attached picture) and the result was the following : C: 52340, R: 12207, G: 24913, B: 11382
Well the sensor figured green was indeed the major color but when I put the result in the RGB tool it showed a complete other green (very dark) than what I expected.
Can somebody explain me these results or are my expectations way to high about the results ?
All ideas or explanations on my findings are welcome.
Jan
- adafruit_support_mike
- Posts: 66315
- Joined: Thu Feb 11, 2010 2:51 pm
Re: RGB values received from TCS34725
Do the readings change as you move the paper farther away from the sensor?
Try using gaps of 1/4", 1/2", and 1".
Try using gaps of 1/4", 1/2", and 1".
- jbyle
- Posts: 8
- Joined: Sat Dec 13, 2014 3:48 pm
Re: RGB values received from TCS34725
Hello,
the readings do change when I move the paper. Also when I put another paper in another color the readings change (which is normal behaviour).
What do you mean with the change of gaps ? Do you mean the ATIME ? I have changed the ATIME to multiple values but that did not change my readings. The readings were identitical with the same paper in the same position on the sensor.
the readings do change when I move the paper. Also when I put another paper in another color the readings change (which is normal behaviour).
What do you mean with the change of gaps ? Do you mean the ATIME ? I have changed the ATIME to multiple values but that did not change my readings. The readings were identitical with the same paper in the same position on the sensor.
- adafruit_support_bill
- Posts: 85867
- Joined: Sat Feb 07, 2009 10:11 am
Re: RGB values received from TCS34725
Mike is asking you you try different distances between the sensor and your target object.
The sensor is measuring reflected light. The intensity of that will vary with the brightness of the light and the square of the distance. The sensor has a 16-bit for a extremely wide dynamic range. Your color tool is using an arbitrary 0-255 intensity scale. Simply truncating the 16 bit values does not necessarily put your sensor readings on the same absolute scale.
The sensor is measuring reflected light. The intensity of that will vary with the brightness of the light and the square of the distance. The sensor has a 16-bit for a extremely wide dynamic range. Your color tool is using an arbitrary 0-255 intensity scale. Simply truncating the 16 bit values does not necessarily put your sensor readings on the same absolute scale.
- jbyle
- Posts: 8
- Joined: Sat Dec 13, 2014 3:48 pm
Re: RGB values received from TCS34725
Hello,
I tried different distances and depending on the distance and angle the values differ but never I come close to the value I expect. The best values I get (but not what I expect) is when the paper has a small angle and is not pushed directly on the sensor (leaving a little space between the sensor and the paper).
I understand your remark on the truncating but I think the grade (light or dark) of green should be fairly similar. Now I get dark green as result for a light green paper above the sensor. If you would know of a site where I could enter 16 bit RGB values, I would be interested to see the resulting color. The ones I found on the internet are 8 bit.
Jan
I tried different distances and depending on the distance and angle the values differ but never I come close to the value I expect. The best values I get (but not what I expect) is when the paper has a small angle and is not pushed directly on the sensor (leaving a little space between the sensor and the paper).
I understand your remark on the truncating but I think the grade (light or dark) of green should be fairly similar. Now I get dark green as result for a light green paper above the sensor. If you would know of a site where I could enter 16 bit RGB values, I would be interested to see the resulting color. The ones I found on the internet are 8 bit.
Jan
- adafruit_support_bill
- Posts: 85867
- Joined: Sat Feb 07, 2009 10:11 am
Re: RGB values received from TCS34725
Not sure what you mean by 'grade'. That is not a term I have seen used in any color system. Using HVC terminology: The Hue and Chroma should be fairly similar (although there are many factors that will affect that too). The Value will be quite variable due to the vast difference in dynamic range between the sensor and your monitor.I understand your remark on the truncating but I think the grade (light or dark) of green should be fairly similar.
http://www.harding.edu/gclayton/color/t ... hroma.html
Even if you had 16 bits of resolution in your color tool, it is physically impossible for your monitor to reproduce the entire dynamic range of the sensor.If you would know of a site where I could enter 16 bit RGB values, I would be interested to see the resulting color. The ones I found on the internet are 8 bit.
- jbyle
- Posts: 8
- Joined: Sat Dec 13, 2014 3:48 pm
Re: RGB values received from TCS34725
Hello,
with grade I mean the fact if it was dark green or light green.
How do I know whether the results I get back from the sensor are correct or not ? I would like to be able to challenge the result I get (RGB 16 bit values) with the color of the object I am holding above the sensor.
Coming back to my first post on this with with picture. The result I got back is C: 52340, R: 12207, G: 24913, B: 11382 Question is, if this is correct when you look at the image ? I would have suspected that the G (green) value would have been a lot higher.
Jan
with grade I mean the fact if it was dark green or light green.
How do I know whether the results I get back from the sensor are correct or not ? I would like to be able to challenge the result I get (RGB 16 bit values) with the color of the object I am holding above the sensor.
Coming back to my first post on this with with picture. The result I got back is C: 52340, R: 12207, G: 24913, B: 11382 Question is, if this is correct when you look at the image ? I would have suspected that the G (green) value would have been a lot higher.
Jan
- adafruit_support_bill
- Posts: 85867
- Joined: Sat Feb 07, 2009 10:11 am
Re: RGB values received from TCS34725
If you are referring to Value, then you can't expect a close match without some calibration. http://www.harding.edu/gclayton/color/t ... hroma.htmlwith grade I mean the fact if it was dark green or light green.
The 'green' color of the paper in your first post does not have a particularly high Chroma, So it is reflecting substantial amounts of red and blue in addition to the green part of the spectrum. In addition to that, unless the surface is an ideal matte surface, you will get some direct (white light) reflections from the LED. Illuminating the paper at more of an angle would probably reduce the direct reflections.The result I got back is C: 52340, R: 12207, G: 24913, B: 11382 Question is, if this is correct when you look at the image ? I would have suspected that the G (green) value would have been a lot higher.
- jbyle
- Posts: 8
- Joined: Sat Dec 13, 2014 3:48 pm
Re: RGB values received from TCS34725
Hello,
what do you mean with calibration ? Does the sensor needs to be calibrated ? The link you mentioned was not complete ending up in a page not found. Can you re-post it ? How do I do callibration ?
Your last remark worries me a little. It sounds to me that you cannot scan the color from any object. The object needs to fulfill some requirements concerning the surface to get the best results. Can you confirm this statement because I was thinking I could scan the color of any object.
How do I know whether the sensor is giving me the right values to avoid the problem is on the hardware level and not related to the software controlling the sensor or the type of surface of the object ?
But to come back to my problem.
My goal is to convert the 16 bit RGB color reading to 8 bit RGB values (I know the 8 bit value will not be as accurate as the 16 bit value). The sensor returns 16 bit values for clear, red, green and blue. So for example to arrive to a 8 bit red, I devide the 16 bit red value with the 16 bit clear value and than multiple with 255 (R/C*255) ? I have found this formula in a piece of source code but I don't know if this is correct or what the theory is behind it. Not sure what the Clear value actually means besides what is mentioned in the datasheet (unfiltered).
Jan
what do you mean with calibration ? Does the sensor needs to be calibrated ? The link you mentioned was not complete ending up in a page not found. Can you re-post it ? How do I do callibration ?
Your last remark worries me a little. It sounds to me that you cannot scan the color from any object. The object needs to fulfill some requirements concerning the surface to get the best results. Can you confirm this statement because I was thinking I could scan the color of any object.
How do I know whether the sensor is giving me the right values to avoid the problem is on the hardware level and not related to the software controlling the sensor or the type of surface of the object ?
But to come back to my problem.
My goal is to convert the 16 bit RGB color reading to 8 bit RGB values (I know the 8 bit value will not be as accurate as the 16 bit value). The sensor returns 16 bit values for clear, red, green and blue. So for example to arrive to a 8 bit red, I devide the 16 bit red value with the 16 bit clear value and than multiple with 255 (R/C*255) ? I have found this formula in a piece of source code but I don't know if this is correct or what the theory is behind it. Not sure what the Clear value actually means besides what is mentioned in the datasheet (unfiltered).
Jan
- adafruit_support_bill
- Posts: 85867
- Joined: Sat Feb 07, 2009 10:11 am
Re: RGB values received from TCS34725
I'll try the link again: http://www.harding.edu/gclayton/color/t ... hroma.html
Here is the Wikipedia article on the same topic: http://en.wikipedia.org/wiki/Munsell_color_system
The problem of scanning the color of an object is surprisingly complex. The problem of reproducing that color on a computer screen or LED is even more complex.
The sensor itself simply reports the R, G, B and C values of the light that hits it. I have very little doubt that your sensor is accurately reporting what it sees. What it 'sees' is every ray of light hitting it. The field of view covers the entire hemisphere in front of the sensor and the angular sensitivity is shown in figure 3 of the data sheet: http://www.adafruit.com/datasheets/TCS34725.pdf
So the first problem is that you need to ensure that the sensor only sees colors reflected from your object. This can be done with some combination of optics, masks and/or shrouds. Just putting the object in front of the sensor does not keep it from seeing other things on the periphery.
The second problem is making sure that the light reflected from the object is not a specular reflection, since specular reflections have the color of the light source, not the color of the object. http://en.wikipedia.org/wiki/Diffuse_reflection If you look at the orange below, you will see an area on the lower left that has white specular reflections from the lights. This will appear to the sensor as a much lighter and paler orange than the light coming from the area just to the right of that.
http://www.rgbworld.com/color.html

Assuming that you have solved the problems of lighting your object and assuring that all the light reaching the sensor is from your object only, It is not sufficient to simply feed the RGB values to a LED and assume they will look the same. The variables here are even trickier:
First, it is unlikely that the R, G and B spectrums of the LED precisely match the R, G and B spectrums of the sensor filters. So exact matches of some colors may be physically impossible.
Next, the R, G and B LED components all have different forward voltages and will respond differently to the varying PWM signal. And, none of the response curves will be linear. The usual technique for correcting this is to implement "gamma correction" tables for each color.
And finally, the human eye does not perceive additive colors synthesized from an RGB LED the same way it perceives reflected colors due to absorption of light on the surface of an object. Plus the fact that our perception of colors is affected by the colors and brightness of its surroundings. The classic book on the subject is "Interaction of Color" by Josef Albers.
Here is the Wikipedia article on the same topic: http://en.wikipedia.org/wiki/Munsell_color_system
The problem of scanning the color of an object is surprisingly complex. The problem of reproducing that color on a computer screen or LED is even more complex.
The sensor itself simply reports the R, G, B and C values of the light that hits it. I have very little doubt that your sensor is accurately reporting what it sees. What it 'sees' is every ray of light hitting it. The field of view covers the entire hemisphere in front of the sensor and the angular sensitivity is shown in figure 3 of the data sheet: http://www.adafruit.com/datasheets/TCS34725.pdf
So the first problem is that you need to ensure that the sensor only sees colors reflected from your object. This can be done with some combination of optics, masks and/or shrouds. Just putting the object in front of the sensor does not keep it from seeing other things on the periphery.
The second problem is making sure that the light reflected from the object is not a specular reflection, since specular reflections have the color of the light source, not the color of the object. http://en.wikipedia.org/wiki/Diffuse_reflection If you look at the orange below, you will see an area on the lower left that has white specular reflections from the lights. This will appear to the sensor as a much lighter and paler orange than the light coming from the area just to the right of that.
http://www.rgbworld.com/color.html

Assuming that you have solved the problems of lighting your object and assuring that all the light reaching the sensor is from your object only, It is not sufficient to simply feed the RGB values to a LED and assume they will look the same. The variables here are even trickier:
First, it is unlikely that the R, G and B spectrums of the LED precisely match the R, G and B spectrums of the sensor filters. So exact matches of some colors may be physically impossible.
Next, the R, G and B LED components all have different forward voltages and will respond differently to the varying PWM signal. And, none of the response curves will be linear. The usual technique for correcting this is to implement "gamma correction" tables for each color.
And finally, the human eye does not perceive additive colors synthesized from an RGB LED the same way it perceives reflected colors due to absorption of light on the surface of an object. Plus the fact that our perception of colors is affected by the colors and brightness of its surroundings. The classic book on the subject is "Interaction of Color" by Josef Albers.
- jbyle
- Posts: 8
- Joined: Sat Dec 13, 2014 3:48 pm
Re: RGB values received from TCS34725
Hello,
thanks for your response. I will have a look on this more in detail later but I just wanted to do a short clarification. I am not using the led. My application only reports the RGB values and than I take those values and put them in a tool like http://www.colorpicker.com/ to see if the RGB values match what I expect.
Jan
thanks for your response. I will have a look on this more in detail later but I just wanted to do a short clarification. I am not using the led. My application only reports the RGB values and than I take those values and put them in a tool like http://www.colorpicker.com/ to see if the RGB values match what I expect.
Jan
- adafruit_support_bill
- Posts: 85867
- Joined: Sat Feb 07, 2009 10:11 am
Re: RGB values received from TCS34725
The problem of reproducing colors on a computer screen is similarly complex. There are tools for calibrating the color fidelity of LCD screens, but there is still a huge disparity in dynamic range between the screen and the sensor. While a good quality screen might have a dynamic range of 1000:1, the sensor has a range of 3,800,000:1. Dividing the 16-bit readings down to keep it in the 0-255 range is essentially performing dynamic range compression. But our eyes do not work that way an the resulting colors are not likely to match what we see.
- jbyle
- Posts: 8
- Joined: Sat Dec 13, 2014 3:48 pm
Re: RGB values received from TCS34725
Hello,
thanks for your response. What is the clear channel (unfiltered color) used for or what does it indicate ?
Jan
thanks for your response. What is the clear channel (unfiltered color) used for or what does it indicate ?
Jan
- adafruit_support_bill
- Posts: 85867
- Joined: Sat Feb 07, 2009 10:11 am
Re: RGB values received from TCS34725
The clear channel is an un-filtered sensor, so it has no color information. It approximates the full spectrum sensitivity of human vision.
- HarvyMatters
- Posts: 1
- Joined: Fri Apr 03, 2015 7:28 am
Re: RGB values received from TCS34725
Hello, Jan,jbyle wrote:Hello,
I understand your remark on the truncating but I think the grade (light or dark) of green should be fairly similar. Now I get dark green as result for a light green paper above the sensor. If you would know of a site where I could enter 16 bit RGB values, I would be interested to see the resulting color. The ones I found on the internet are 8 bit.
please try to divide 16 bit RGB received values to 256, and see what happens.
Please be positive and constructive with your questions and comments.