ColorPAL Object and ColorPAL VGA Demo
Phil Pilgrim (PhiPi)
Posts: 23,514
Attached is a demo written for the new ColorPAL RGB color sensor and the Propeller Demo Board. It displays color data and an interpretation of the color the ColorPAL sees on a VGA screen. Included with the demo program is a ColorPAL object that can be used with your own programs.
The first thing the demo program does when it starts is a white balance. This means that when the program starts, the ColorpAL needs to be looking at something white. If you save the demo in EEPROM, you can take a new white balance whenever you press the RESET button. By calibrating the ColorPAL to a known white color, each raw RGB component sensed afterward can be referenced to and corrected by the white components, as follows:
····CorrectedR,G,B = 255 * RawR,G,B / WhiteR,G,B
To keep things running smoothly, each color read is corrected to white and averaged over sixteen samples. The average RGB values are then displayed on the screen. Showing the actual RGB color on the screen is a bit more complicated. Although each sensed RGB color component can range from 0 to 255, each displayable color component can take on only one of the four values 0, 85, 170, or 255 ($00, $55, $AA, and $FF). The simplistic way to convert a sensed color to a displayed color would be to pick the value among the four displayable ones that's closest, for each RGB component. Unfortunately, this does not give the best results. Consider the color purple, as sensed by the ColorPAL: its RGB components are (76, 58, 86). Clearly, there's more red and blue than green. But the nearest VGA value to each of those is 85, and (85, 85, 85) is dark gray.
It turns out (after a lot of experimenting) that the simplest way to get a reasonable VGA color approximation to the sensed color is just to multiply the sensed components by each of $0.C0, $0.C1, ..., $1.3F, $1.40 (i.e. 0.75 to 1.25), convert each product that's no bigger than $FF by shifting right by 6 and pack the results into a 6-bit number to yield an index into the 64 VGA colors. Then the program keeps track of how many times each VGA color gets a "hit" over all the multipliers. The one that gets the most hits wins. The result is a pretty fair representation of the sensed color, to the extent that one of the available 64 colors can represent it.
Here's a photo of the ColorPAL looking at "Wasabi Green", one of my more troublesome colors:
Here's a representation of the VGA output screen:
BTW, in the spirit of full disclosure, I did photoshop this to match the color actually displayed on the VGA screen, rather than the washed-out color my camera recorded.
Anyway, if you have a ColorPAL (they're only $19.99, after all ), get some paint chips from your local hardware store, and give this program a try!
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 12/30/2009 5:16:59 AM GMT
The first thing the demo program does when it starts is a white balance. This means that when the program starts, the ColorpAL needs to be looking at something white. If you save the demo in EEPROM, you can take a new white balance whenever you press the RESET button. By calibrating the ColorPAL to a known white color, each raw RGB component sensed afterward can be referenced to and corrected by the white components, as follows:
····CorrectedR,G,B = 255 * RawR,G,B / WhiteR,G,B
To keep things running smoothly, each color read is corrected to white and averaged over sixteen samples. The average RGB values are then displayed on the screen. Showing the actual RGB color on the screen is a bit more complicated. Although each sensed RGB color component can range from 0 to 255, each displayable color component can take on only one of the four values 0, 85, 170, or 255 ($00, $55, $AA, and $FF). The simplistic way to convert a sensed color to a displayed color would be to pick the value among the four displayable ones that's closest, for each RGB component. Unfortunately, this does not give the best results. Consider the color purple, as sensed by the ColorPAL: its RGB components are (76, 58, 86). Clearly, there's more red and blue than green. But the nearest VGA value to each of those is 85, and (85, 85, 85) is dark gray.
It turns out (after a lot of experimenting) that the simplest way to get a reasonable VGA color approximation to the sensed color is just to multiply the sensed components by each of $0.C0, $0.C1, ..., $1.3F, $1.40 (i.e. 0.75 to 1.25), convert each product that's no bigger than $FF by shifting right by 6 and pack the results into a 6-bit number to yield an index into the 64 VGA colors. Then the program keeps track of how many times each VGA color gets a "hit" over all the multipliers. The one that gets the most hits wins. The result is a pretty fair representation of the sensed color, to the extent that one of the available 64 colors can represent it.
Here's a photo of the ColorPAL looking at "Wasabi Green", one of my more troublesome colors:
Here's a representation of the VGA output screen:
BTW, in the spirit of full disclosure, I did photoshop this to match the color actually displayed on the VGA screen, rather than the washed-out color my camera recorded.
Anyway, if you have a ColorPAL (they're only $19.99, after all ), get some paint chips from your local hardware store, and give this program a try!
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 12/30/2009 5:16:59 AM GMT
Comments
Now we just need to reinstate the parallax inkjet kit, version 2 with color cartridges, and we can tint our own paint cans
The other vital use I see for that is settling those long running arguments with significant others about 'salmon' hues, and whether they are in fact pink, or orange...
I was wondering about determining colour using normal LEDs using the fact that they can convert light to volatge/current and presumably do it over a narrow spectrum. So, three normal LEDs, red, green, and blue used "backwards" could be used to get the colour. No colorPAL required.
Of course that might work for determining the colour of bright ambient light but to do what the colorPAL does one would need broad spectrum white light source. Surely a white LED would not do. Or could one use another triplet of LEDs to provide the matching RGB illumination?
Calibrating all of that might be an issue.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
White LEDs are not as bad as one might imagine. Although the emissive source is blue, that's used to excite a white phosphor, which has a broad-spectrum output.
kuroneko,
The Demo Board pictured is the first model made. (I must remember not to use it for forum photos. I always get asked about it. )
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
-Phil
P.S. That is the most rediculous looking demo board I've ever seen! Thank goodness for revisions!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Computers are microcontrolled.
Robots are microcontrolled.
I am microcontrolled.
But you·can·call me micro.
Want to·experiment with the SX or just put together a cool project?
SX Spinning light display·
My overstock is killing me.
PM me for absolutly FREE 8-pin Mini Din connectors.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
It's documented in the LED's datasheet: www.all-tronic.com/pdf/NSPW500BS.pdf.
(To viewers who might just be joining, this discussion of white LEDs has nothing to do with the OT (i.e. ColorPAL), which uses an RGB LED.)
-Phil
This looks like a nifty way to monitor a slow biochemical process remotely with one glance at a VGA screen.
Thanks, Phil !
Wasabi green. Hmm.
For some reason I'm thinking "sushi" for lunch.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
You need the VGA monitor. The limited color gamut available in the Propeller's video output renders it much less useful for displaying sensed colors.
-Phil
Meaning like 5 LED's red, green, blue, yellow, white instead of using VGA? Is it possible to alter the code in this way and simply light up the most appropriate LED color based in the color the sensor read?
As an alternative, you could use an RGB LED like the one in the ColorPAL and PWM the RGB segments to match the RGB values returned by the ColorPAL.
-Phil
Np, i will wait untill i'll get smart enough to understand what file from yours to modify and how.
My Boe Bot have gripper and IR, I would like to modify the bot to add color sensor TCS 3200 DB, I do not know what i need to do with the programming. Can anyone assist me. Thank you
Yours Sincerely
James