The canonical "scrolling rainbow" I showed in Part 2 used a very simple (and naïve) HSV-to-RGB converter to generate the RGB rainbow. However it wasn't very satisfying, because RGB values by themselves bear only a passing correlation with actual colors. If you have ever worked with digital photography or graphical design, you'll understand exactly what I mean. A given picture or image on your laptop's screen will probably look noticeably different on another screen (without calibration and the assistance of software meant to correct these things). An RGB value of 65, 0, 255 - a nice, satisfying violet color on my laptop - only communicates to the display device, "set your red output to 65/255 of its maximum output; turn your green output off; and turn your blue output all the way on." It says nothing about what the exact meaning of "red", "green", and "blue" is supposed to be, and puts no constraints on the linearity of each of those components when displaying values from 0 through 255.
As I have time, I think the next thing I want to do is to look into color representation schemes and figure out how to quantify the gamut produced by these SMD5050s, and also investigate perceptual color representation. I'd like to be able, say, to produce a rainbow wherein only the hue appears to change, but not the apparent brightness.
We'll have to see to what extent work and other aspects of life get in the way this week...
I'll leave you with one more bit of eye candy; this shows three separate intensity "waves" - one for each RGB channel - moving at slightly different speeds, with an update rate of 120 Hz:
No comments:
Post a Comment