Implement DN40 algorithm for color temp conversions

[microbuilder]

The Arduino library was recently updated to include a new RGB to CCT algorithm based on the DN40 app note from Taos (now AMS): adafruit/Adafruit_TCS34725@116a9aa

This function should also be implemented here since it's far more accurate that the current color temperature algorithm.

[ladyada]

@caternuson is thjis something you wanna try implementing after TMP006?

[caternuson]

@microbuilder you self assigned. I take that to mean you're wanting to do this update? I could probably code this up, esp. with the Arduino code as a ref. Let me know - don't want to duplicate effort.

[microbuilder]

@caternuson If you want to have a go at it, feel free! I tried to document the Arduino code as thoroughly as possible, so the thinking behind all the calculations is there but check DN40 for further details.

That Arduino function also does a better job at converting lux, though it isn't used in the Arduino case. But the lux conversion over there should give better results than we have today in the CP code.

[microbuilder]

There are some potentially useful notes in the comments of that function like ripple rejection, and minimum/maximum thresholds for accurate data if you really want to go overboard on the CP implementation, but it's up to you.

It's worth maintaining the comments as future signposts, though, since they at least highlights some issues you may have with the data.

[caternuson]

Thanks. I'll give it a go then.

I'm not sure this answers the mystery of the origin of color_rgb_bytes though. If you find a reason for why that's there, please let me know. Otherwise I'm thinking it might just disappear as part of this update.

[microbuilder]

I suspect it's just a trial and error fudge. The raw RGB values from sensors like this don't have a direct relationship to RGB like we're used to seeing such as #AABBCC on a webpage or 24-bit sRGB values. Each sensor and each photodiode on the sensor will have a distinct response curve, and the 'weight' of each photodiode isn't necessarily equal ... so say red might have a relative weight of 0.7 to green's 1.0, etc.

There is also something described in DN40 called the 'Device Factor' and 'Glass Attentuation' which account for physical characteristics of the sensors and the enclosure of optics the light passes through before it hits the silicon photodiodes. adafruit/Adafruit_TCS34725@116a9aa#diff-3b1fa3e4ed42a3d766e25e7cd51a93aaR421

I think we can just drop this code once a good alternative is found, but I'm 95% certain it is a trial and error best guess. Once we have CCT, it's possible to do a more accurate conversion to a standard RGB working space via CCT->XYZ->sRGB(etc.).

[microbuilder]

@caternuson I linked to another issue discussing this chip but in Arduino-land, and you can find the DN40 app note there along with an alternative approach converting from raw RGB to XYZ using a 3x3 correlation matrix. The latter approach, however, requires that you also have access to a calibrated spectrometer and the accuracy of the conversion results will depends on the 3x3 correlation matrix you use so it should ideally be done with a specific light source, not a catch-all general purpose 3x3 matrix since LED light is very different spectrally than sunlight, than fluourescent, etc.

Color theory is really interesting to me, but it gets complicated quickly, alas. :P

[caternuson]

OK. Finally got a PR in for this. Check it out. #17

sry this took so long, turns out the endianness of the 16 bit read/write was wrong and wasted tons of time thinking it was my DN40 implementation.

[microbuilder]

Thanks for the PR! I'll put my comments in #17.

[caternuson]

Closing. DN40 implementation added with #17 .