-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sharing a Refined Approach for TCS34725 Color Calibration #4
Comments
Wow, this is awesome! Back then, I really made this to get a more accurate implementation than what the Adafruit library had. I ended up using some of this code on a workshop I presented in 2019, and I have to confess that I haven't really touched it since then. Luckily I work in an environment where I have access to optical instruments that can work much better than this thing. I have to say, I really found the colour gamut on these things rather limited, but I suppose I cannot complain at this price. I also have to confess that I am not really a home automation afficionado, but I can see how this thing can be used to fine-tune colour temperatures from different illumination sources. Anyway, thanks for letting me know, I hope your code ends up being accepted, and KBO! |
Hey @ha5dzs, well, the whole issue I'm trying to solve right now is that the manufacturer provided Lux calculations are super crude, as they are for D40 and have a negative coefficient for the blue channel. So solely blue light will return negative lux values. The CIE1931 colors I've implemented leaves us with more believable values for Lux on the Y channel and gives the ability to report the color temperature as NAN (invalid) K if we're outside the plain white spectrum. But it's far from perfect, as the simulations are super crude compared to real measurements. I also bought an AS7261, which is like 45 bucks here in Germany. But it's calibrated and will return calibrated CIE1931 X, Y, Z values and calibrated Lux and calibrated color temperature. The idea was to compare what the TCS34725 is measuring to this one, to make more data points as reference for the conversion matrix, so it's more accurate. Sure, it won't beat professional equipment and the AS7261 is probably also quite crude compared to them, but it should be enough to get proper colors out of the TCS34725 to get more reliable Lux and white temperature values. The use cases I see for this would be to measure the ambient white temperature from outside and replicate it indoor, as well as measure the indoor brightness, to dim down the lights, if there's enough ambient light from outside. The AS7261 however is planned for expanding the measuring script of PowerCalc to make color/brightness correction profiles for smart lights. So different smart lights will output roughly the same color. If you got access to more advanced equipment, however, it would be great if you could supply better color calibrations for the TCS34725 or help me in planning the color calibration process for lights with the AS7261. :) |
The only good thing about this sensor is that it is cheap. This Osram thing looks really cool, I'll try to get one for let's say 'entertainment' purposes. :) Unfortunately there is a limit on what can realistically achieved with the TCS sensor.
Perhaps an immediate application would be to match the presented colours of different light sources. I think it will be much more reliable in making comparative measurements than absolute measurements. Each RGB light has different primaries and relative intensities, and it is very difficult to match them. Setting the correct gains and integration times will be tricky too. I am not even sure if it is possible in all scenarios, as the lights could produce colours that are outside of the colour gamut on the TCS sensor. Maybe a smart light, in xy mode, and to fine-tune the values... In the lab I have access to a Minolta CS-150 and a Sekonic C-800. Both of them are four figure instruments. In the near future (once/if the Prof greenlights it), I am planning to upgrade our low CRI LED lights with a series of Philips Hue lights, and I got some code written for it to work in a mildly controllable manner. My initial measurements show that they are pretty good at generating colours accurately. Once I get it installed in the lab, I will have some decent level of control of illumination intensity and colour. But, I can't promise when this will happen. When it does, I'll post the data. |
Not sure where you are located. But that's currently the cheapest offering in Germany: Its default communication is UART, which is also a bit easier to write, I2C is available by resoldering some resistors in a different position.
Well, yeah, but ESPHome has already auto gain implemented, which follows the saturation and keeps the clear channel at 60% saturation based on the previous measurement - which works great until around 13k Lux, if you use an update frequency of 1s or so. I've thrown out the clear channel, as it's absolutely not useful for anything (except maybe color response corrections - I'm not sure about this) and this opens the sensor up to read up to 83 kLux, which makes it much more useful. PR in ESPHome is currently pending: esphome/esphome#7508
Yeah, I mean we're talking about measuring the room brightnesses, and steering the lights brightnesses. Like say, you put one sensor on your desk and set the brightness to 1000 Lux and your smart lights keep the brightness at least at that level. I use this in one room atm, and it works really great. The main issue right now is that if you have smart lights, you want to use something like Adaptive Lighting - basically like the blue filters/reading mode/night mode for smartphones. So, your lights cycle through different white balances and brightnesses over the course of the day. So it's nice if the tcs34725 would output consistent Lux values throughout the range of white balances and isn't disturbed by say a user turning on some ambient lighting in blue or red or green. I'm not necessarily interested in absolute accuracy, but relative accuracies throughout the color range in the ballpark where the brightness is. So say if it's reading 900 Lux or 1100 Lux instead of 1000 Lux, that wouldn't be a big issue in this application - as long as it's consistent. And for that, the 3 dollar sensor is fine - I think.
Yeah sure, that's more of a job for the AS7261 to create color correction profiles for lights, but buying an AS7261 for each room in your home to measure the brightness of the room is a bit of an overkill ;)
I feel you. That's why we all use ESPHome and Home Assistant ;)
Yeah, those feel a bit overpriced to me. But that's one of the things I like to learn by measuring my different lights. I'm currently pretty happy with my Livarno ones, which are rated with >= 95 CRI and pretty cheap :)
Cool! Would be nice if you could throw one of them under a couple of different light sources and the bare tcs34725, too, and tell me CIE1931 X/Y/Z and the raw sensor values of the TCS34725 plus Integration Time and Gain! If you use ESPHome you can enable the debug logging which will list all of these things, while it keeps with auto exposure the exposure at around 60% :) |
We have RS over here too: I am thinking of making a board for a Flipper Zero. Eventually.
I used it for gain control in one of my demos. But yes, not inherently useful.
In the lab, it's the other problem. You want to maintain illumination and chromaticity no matter what.
The sensor itself is cheap. But say, getting an Ikea Tradfri light to create the same chromaticity as some other honka bonka light would be a plus. It could be used as a handheld instrument or similar.
They are very expensive. But have you seen the green primary of these though? Absolutely beautiful. Almost monochromatic. It will be ideal for the lab though.
As of now, I haven't been able to get into this yet, mostly because I am reluctant to connect my home stuff to the local network. Not because I am concerned that someone may hack into it, but because I don't think it has the necessary stability. And I really don't want to get frustrated at the inability to turn a light on because my router decided to lock up and no longer forwards packets. Zigbee is cool too, but it is prone to interference from other things on the 2.4 GHz band. I have been playing with ESP32-C6s recently, and I am not really happy with the 2.4 GHz stuff. |
I've been using Zigbee for four years now, haven't seen any interferences yet. The low range you need in a home and high number of devices you usually connect to the network makes it extremely robust. Regarding ESPHome: I've got an OpenWRT router which does the Wifi. Haven't had to restart it in the last 8 years. It's rock solid. ESPHome got it dedicated WLAN on it and my regular internet is connected via wire to the two OpenWRT Hotspots.
Yeah, that's what it was used in ESPHome, too. But it makes no sense, as this means the color channels get 3 times less light and will produce less accurate signals. The only thing it maybe useful is to calculate out crosstalk between channels. But how much this would actually help is debatable. |
I wanted to share that I recently did something similar but took it a step further for integration into ESPHome. After finding your repo, I thought it might be helpful to share my approach with you.
The spec sheet doesn’t just provide the responsivities but also includes different light responses in counts/µW/cm² for the clear channel. These can be used to calibrate the matrix with known light sources, as described in the PDF provided by the manufacturer. By simulating these light sources onto the clear channel's responsivity, it allows for more precise calibration.
You can find my code here:
https://github.com/RubenKelevra/tcs34725-irradiance-correction/
And here’s the PR where I implemented it for ESPHome:
esphome/esphome-docs#4351
The text was updated successfully, but these errors were encountered: