I am wanting to create a RGB sensor that will provide data output of the RGB colour values of a piece of material or paper ie possible use for colour matching.
I have seen the following “TCS3200 RGB Color Sensor For Arduino is a complete color detector , including a TAOS TCS3200 RGB sensor chip and 4 white LEDs.”
I have limited low python experience but can learn and looking for something cheap and easy to put together.
Someone has mentioned the use of #CE07823 ( PiicoDev Colour Sensor VEML6040) with a Raspberry Pi Pico
Could someone recommend a package of items that will enable me to do this.
2 Likes
Hey Steffan,
Welcome to the Forums!
I think I spoke with you earlier and recommended our PiicoDev colour sensor. Ive got the guide linked here for how to set it up and a basic look at what the RGB value looks like via this sensor. I think it would be a greatly affordable option and much easier for you to set up than a lot of the other colour sensors we may have from Adafruit.
Cheers,
Blayden
2 Likes
Hello Blayden
After some time spent with the VEML6040 colour sensor, it is not giving the required results with a Pico. Colours either as RGB or HSL do not align with actual colours. Are there other colour sensors that will work with a Pico or Zero. I am looking at a colour sensor with some general accuracy for colour matching or comparison to RGB/Hex or HSL values.
1 Like
Hi Steffan
What are you comparing this with. I am just interested that is all. An interesting experiment is using a photo editing program run the cursor around and somewhere you should see the RGB values displayed. Could be in small numbers at the bottom or one corner of the screen. Some of the results might surprise.
Also if the subject is illuminated the colour temperature of the illuminating source will have an influence.
I think something like this came up when Core introduced their sensor and they were very much aware of the problem and the source used is apparently as pure white as they could get or something like that. If you search the forum using the Core SKU or sensor type you should find this (these) discussion.
Cheers Bob
1 Like
Thanks Bob. Got the SKU number now.
1 Like
VEML6040 - I have set up a couple of Py scripts for each of the Hue and RGB information and summarised information. I have looked at the standard ROYGBIV colours and Black White and Grey and compared this to standards for these key colours. Hue from 240 degrees onwards gives diff values ie Indigo Violet and Magenta. RGB values - I have been able to create a rough RGB value assuming one of the colours has Red, Green or blue as 255 and calculating other values accordingly.
Black, white and grey incorrect and give the same result.
Have started to look at other variables like distance from sensor and lighting but this will not make up difference I am looking at.
There is also other information available on the sensor like Colour Temp(K), Ambient Light, Hue Saturation & Value. No value at the moment.
Either logic in the colour sensor needs to be changed or I need to find another sensor. Any recommendations for a sensor to find close colour RGB matches for Pico or Zero
1 Like
I am using the sensor to compare against basic colour samples.
I use Excel
Select a cell(s) / Format Cells / Fill / More Colours / Custom / RGB.
Enter RGB numbers of colour required
RED (255,0,0), Blue (0,0,255)
These colours can be printed out (minor variations due to printers) or viewed on screen.
Among various other ways, can use FireFox browser to check colours on screen.
Firefox / More Tools / Eye Dropper.
This gives the Hex# colour number which can also be converted to RGB number.
Can send PDF as well as web pages to Firefox to view for colour testing.
Hi Steffan,
Very interesting dive!
Whereabouts were your results differing during your testing? Would it be possible to show your testing process and the code you used?
To get a baseline it might be worth using a scanner to re-digitise your printed examples to get a baseline for comparison.
Keen to see this one figured out Steffan!
Liam
Hello Liam
Can you send me an email directly and I can reply with attachments and overview of testing process.
Txs
1 Like
Hi Steffan,
Is there any reason that it couldn’t be shared to the forum? That way more people can give their input
I have tried to calibrate the VEML6040 to get RGB values using these 12 standard colours printed out. I then placed each of these colours individually on top of the sensor and at 1cm height to obtain comparison readings.
01 Attached is a standard list of 12 colours with their values.
02 In Excel I created a set of 12 colour swatches using RGB values which I printed out and used to place over the Colour sensor - both directly on top and at 1cm above.
03 summary of testing results.
04 Colour testing includes summary outputs of various colours. Also included are two Python scripts that have dual outputs from Thonny - to screen and to the Pico as an HTML.
If you do not see output on the Pico first time, in Thonny press STOP to reconnect the Pico to refresh the view and the html file will appear. In Thonny right mouse click on the file in the Pico and download this HTML via Thonny to the PC to view. Use windows explorer to open on the PC and the html file will appear in your browser. The Input comment field is appended to the file name to keep track of testing results.
In the script ColourSensorRGBHexHTML.py I had to make an assumption to base one of the R,Gor B colours as saturated and give it a value of 255 and the other two colours were then a fraction of this. RGB colours using this are not accurate. The HTML file has RGB to Hex# conversion to display the colour. If I did not make this assumption then colours were meaningless.
The raw RGB values produced from the colour sensor are not in the same ratio as the actual colour.
In the script ColourSensorHueHTML.py, the Hues produced do not align well with the HUES colour wheel to 360 degrees. In particular after 240 degrees colours do not align. Values for Saturation and Value to get HSV values do not appear relevant.
Sorry about the Python programming - can do better.
If I cannot get more accurate values, then which sensor will give me better RGB readings with a Pico or Zero?
01 Colour_RGB_Table.pdf (32.2 KB)
02 ColourSensor_Colour_Match ROYGBIV.pdf (62.3 KB)
03 ColourSensor_TestingResults.pdf (38.1 KB)
04 Colour_Testing.zip (5.8 KB)
1 Like
Hi Steffan,
Running some tests now, I think there are better methods to calculate the equivalent RGB value on your end but measuring light accurately in non-ideal environments wont yield an amazing result regardless.
(Normalising with respect to all of the outputs should yield a closer result)
Hi Steffan
Colour measurement is one of the most challenging area in the lighting engineering field. Even the definition of colour in still subject to a lot of vigorous discussions in conferences.
This link gives a good initial intro to the challenges. Colorimetry: How to Measure Color Differences | Test & Measurement | Photonics Handbook | Photonics Marketplace
I have taught lighting engineering at RMIT as a Member of the Illuminating Engineering Society, and unless you can control (eliminate) as many variables as possible - your results will wander about a lot.
In particular, defining a colour on a computer screen, then printing out a swatch via an inkjet or laser colour printer immediately drops you into two different colour spaces (RGB → CMYK) with the inherent translation calculations and errors. Then you have the difference between the colour of light emitted by the screen–which is dependant on the type, age and setup of the screen (CRT/LED/OLED/Plasma(!)) and the colour temperature of the light source being used to illuminate the printed samples, the quality of the inks, the base purity of the ‘white’ paper etc etc …
Noting that while Core have tried to use a ‘good’ light source for the VEML6040 sensor …
- Any LED source is NOT a continuous spectrum source - it has spikes and dips and gaps in the emitted spectrum.
- The LED has a higher (i.e bluer) colour temperature than the ‘standard’ light source used in measurements-typically a specified incandescent source.
- If there is any other light source (daylight/desk lamp/room light) that is lighting the test area, then again you have an uncontrolled situation …
The best you can do is to create a test chamber that only has the VEML6040 sensor in it, establish a standard test distance to the sample, and compare your results with each other only, and/or determine the ‘correction values’ yourself with respect to the values you used to create and print your samples.
Then you have a better chance of being able to test ‘unknown’ samples and making a reasonable estimate of the RGB value.
Otherwise you are up for an expensive test system that can be regularly calibrated / verified at a NATA registered laboratory. Such a device has the most accurate/calibrated tristimulus sensors etc etc … and you pay for it.
At our ‘Maker Level’, the VEML6040 is a great sensor (yes I have one also) but one must be aware of the cost/value equation. Treat it with knowledge of its’ capabilities and limits and it works very well.
Cheers
Murray
2 Likes
Hi Murray
Very well put.
I think
that statement just about sums it up nicely. There are just too many variables to make any definitive statements. I think that quote applies to just about any measurement situation. Be aware of any limitations regarding any test equipment in use and environmental situations. Learn to assess and evaluate any results you see with all limitations and/or situation at the time. For instance say your multimeter reads 4 decimal places on the lower range. You can’t expect to measure voltages to 0.1mV which the 4th digit implies. your meter probably has an accuracy spec 0.5% or maybe a bit better BUT it will also have the all important something like +5 digits which means the last digit could fluctuate 5 digits from any reading. This would make the meter good for something like 1mV instead of 0.1mV. This X% + something will apply to all ranges so a reading of 500.3mV usually means somewhere near 500mV.
If this line of thinking is applied more often there would not be so many panic situations when someone reads say 5.15V instead of a quoted 5.2V. The error could even depend on your actual probe contact on the measurement point. In other words realise small errors from quoted numbers are likely and mostly mean nothing.
Cheers Bob
2 Likes
Adding in a simple Py script that I created that converts RGB Colours to Hex and HSV to screen as well as HTML on the Pico.
05 ColourConverter.zip (1.6 KB)
Thanks Robert.
My father worked in the SA Electricity Trust Standards & Test Lab. They did have meters that would show 6 decimal places or more depending on the meter … some which you would not necessarily think of as a meter, but were more correctly a ‘metering system’. They could tell you that the RMS value of the mains power was actually 240.342576 Volts at the given moment of measurement. But they would report it on official records as 240.3426 volts ‘as within the acceptable range of measurement accuracy and precision’. And note that accuracy and precision are very different concepts.
See this page from sketchplanations.com
Murray
1 Like
Hi Murray
I worked at AWA North Ryde for 22 years and their test instrument section was a NATA certified establishment with Rubidium frequency standards Electrostatic voltmeter (the only one I have ever seen) and sundry other very salubrious standards. They could measure down to some decimal parts of a mV. The 1MHz and 10MHz frequency standards were piped all over the factory using distribution amps for all to use. Particularly the test rooms.
BUT, I would be confident in saying you would never find such instruments in a good workshop never mind the average hobbyist workbench. probably because there is no reason for this resolution in the user environment. I would guess that for most measurements 1mV would be good and 10mV still OK for most applications.
Annual calibration checks ?? I think that means that the last few measurements made and the next few could be regarded as within tolerance. Anything in between could still be anywhere but a line has to be drawn somewhere and if anything unusual is happening with measurements instrument calibration is one thing which should be verified. I have often asked the question, if an instrument is found to be incorrect at Cal time how far do you go back with suspect results or particularly adjustments and settings made. Actually I think most run of the mill DMMs are only within tolerance with a fresh battery.
In practise all this softens a bit if you know and can appreciate your instrument limitations and need not be a big problem. After all it is not a big deal to put a new battery into a DMM if measurements are suspect
But this is digressing a bit from the original post. Interesting all the same.
Cheers Bob
1 Like
Hi Steffan and Robert et al,
I think that the core (no pun intended) aspect of Steffans’ work and our comments comes down to learning about, understanding, and working within the bounds of whatever system one is using / creating.
This applies to our Makerverse, and to the NATA labs, and everyone in between.
And while finding and knowing one’s limits, keep looking beyond… the next advance in knowledge is just … out … . . . … . there
Cheers
Murray
Here is an old example that someone created using Arduino
https://richnelson.me/side-project/2016/02/10/colorimeter.html
Again using the same assumption of setting one of the colour channels R,G,B to 255.
I am trying to do the same but am sure there are more accurate Colour sensors that provide more accurate information.
Just looking for a simple Pico project to analyse colours with at least a 256 colour palette defined through RGB or HSV colours.
