Color sensor 88007 is returning values > 255 in rgbMode
dkurok opened this issue · 7 comments
I've played arround with the ColorDistanceSensor-implementation from @highstreeto today.
Using the ExampleColorDistanceSensor.cs and have it run a little bit longer in await TestMode(colorDistSensor, colorDistSensor.ModeIndexRgb) for better checking what it returns, I mentioned that it receives red, green and blue values GREATER than 255! (try over a clear white surface for getting fast to it).
The "SharpBrick.PoweredUp.Cli.exe device list" gives this for the RGB-sensor
Mode 6: Name: RGB I, Symbol: RAW, Capability: Input
- DataSet: 3x Int16, TotalFigures: 5, Decimals: 0
Input Mapping: Absolute
Raw Min: 0, Max: 1023
Pct Min: 0, Max: 100 (scaling)
SI Min: 0, Max: 1023 (pass-through)
So the values can be up to 1023! (10 Bit)
But does this make sence?? Wouldn't it be better if the implementation in sharpbrick.poweredUp would "normalize" these values into a range of 0..255 for further working with the RGBV-values in a .NET-manner? Or should it be the library-users responsibility to normalize?
Interesting enough:
You can determine the light that the Hub'S LED shines:
And for this "device list" gives:
Port: 0x32 / 50
- IOTypeId: RgbLight / 0x0017 / 23
Revision: SW: 1.0.0.0, HW: 1.0.0.0
Capabilities: Output
ModeCombinations: []
- Mode 0: Name: COL O, Symbol: , Capability: Output
- DataSet: 1x SByte, TotalFigures: 1, Decimals: 0
Output Mapping: SupportFunctionalMapping20 Discrete
Raw Min: 0, Max: 10
Pct Min: 0, Max: 100 (scaling)
SI Min: 0, Max: 10 (pass-through)
- Mode 1: Name: RGB O, Symbol: , Capability: Output
- DataSet: 3x SByte, TotalFigures: 3, Decimals: 0
Output Mapping: Absolute
Raw Min: 0, Max: 255
Pct Min: 0, Max: 100 (scaling)
SI Min: 0, Max: 255 (pass-through)
So here they restrict it to 0..255 (8 bit)
Problem is: this scaling is integral part of the LWP. I did not realize at the beginning which led to the unfortunate decision to have input data type == output data type. We will fix this by making the output a double. Decimal might be another choice but has a price on memory.
This is by the way the trigger for the v4 release in the first place.
Wow. Sorry. Completely misread this thread. Good question. Well, same answer... We implement first of all LWP and powered up devices. They create a 1024 discrete color spectrum. Do I like it. Nope. Is a helper method maybe useful? Maybe. Will the endpoint use 1024 for the si endpoint? Yes
Same story for other color sensors btw
Yeah, I noticed that behavior too.
I added that in my PR for the docs repo.
Good First Issue:
Create an extension method which translates the 0-1000 value to a realistic RGB scale from 0-255.